
							130-100-005-01


SUBJECT:  PDP-11 DISK MONITOR FUNCTIONAL SPECIFICATION

FROM:	  HARLAN SHEPARDSON			DATE:	DECEMBER 1, 1970
	  ROGER WILLIS





























		THE INFORMATION IN THIS MEMORANDUM IS
		SUBJECT TO CHANGE WITHOUT NOTICE AND
		SHOULD NOT BE CONSTRUED AS A COMMIT-
		MENT BY DIGITAL EQUIPMENT CORPORATION.

		PDP-11 DISK MONITOR FUNCTIONAL
			SPECIFICATION

0.0	INTRODUCTION

0.1	IDENTIFICATION

0.1.1	TITLE

	PDP-11 DISK MONITOR FUNCTIONAL SPECIFICATION, VERSION 3,
	DECEMBER 1, 1970

0.1.2	AUTHORS

	WRITTEN BY HARLAN SHEPARDSON AND ROGER WILLIS

0.2	SCOPE

	THIS SPECIFICATION DESCRIBES THE SINGLE USER DISK-RESIDENT
	MONITOR FOR THE PDP-11.  THIS SPECIFICATION WILL ATTEMPT TO
	DEFINE THE USER FOR WHICH THE MONITOR IS INTEDNED, TO DESCRIBE
	THE BASIC COMPONENTS AND CAPABILITIES OF THE MONITOR,
	AND TO DESCRIBE USER/MONITOR INTERFACES IN SOME DETAIL.
	FUNCTIONAL SPECIFICATIONS FOR MONITOR COMPONENTS AND 
	INTERRELATIONSHIPS WILL ALSO BE PRESENTED.

0.3	REFERENCES
	
	NONE

0.4	CONTENTS

	THIS DOCUMENT IS ORGANIZED ACCORDING TO THE STANDARD FOR
	FUNCTIONAL SPECIFICATIONS AS SET FORTH IN THE PROGRAMMING
	PROJECT CONTROL STANDARD.

1.0	OVERALL DESCRIPTION

1.1	USAGE

	THE DISK MONITOR WILL PROVIDE SERVICES TO THE USER IN TWO
	AREAS - PROGRAM DEVELOPMENT AND RUNNING OF THE DEVELOPED PROGRAMS.

	DURING PROGRAM DEVELOPMENT THE MONITOR SERVES THE USER BY
	PROVIDING A SIMPLE, STANDARD INTERFACE WITH PROGRAM DEVELOPMENT
	SOFTWARE SUCH AS THE ASSEMBLER, COMPILERS, DUMPS, ETC.

	DURING PROGRAM EXECUTION THE MONITOR EASES THE BURDEN ON THE
	USER PROGRAM BY PROVIDING COMMON I/O DEVICE HANDLING ROUTINES,
	LOADERS, OPERATOR INTERFACE, ETC.

	THE MONITOR WILL BE DESIGNED IN A MODULAR FASHION SO THAT THE
	USER CAN SELECT (AND PAY THE OVERHEAD FOR) ONLY THOSE MODULES
	WHICH ARE REQUIRED FOR HIS APPLICATIONS, AND ALSO HE MAY EASILY
	PROVIDE HIS OWN MODULES FOR FUNCTIONS NOT SUPPORTED BY THE
	MONITOR.  THIS SELECTION PROCESS WILL BE SUPPORTED THROUGH AN
	AUTOMATIC SYSTEM GENERATION TECHNIQUE.

1.2	MARKET

	THE PDP-11 DISK MONITOR IS INTENDED FOR USE BY A WIDE
	SPECTRUM OF PDP-11 CUSTOMERS WITH A WIDE RANGE IN 
	SOPHISTICATION.  ITS USE IN CONJUNCTION WITH ASSEMBLERS, COMPILERS,
	ETC. SHOULD APPEAL TO ALL LEVELS OF USERS FOR PROGRAM DEVELOPMENT.
	SINCE THE MONITOR WILL BE MODULAR, SOPHISTICATED USERS
	WILL BE ABLE TO USE PARTS OF IT IN THEIR SPECIALIZED SYSTEMS.
	THE MONITOR WILL BE EASILY EXTENDED TO PROVIDE JOB PROCESSING 
	IN A "BATCH" ENVIRONMENT WITH OPERATOR INTERACTION.  THE MONI-
	TOR/USER INTERFACE WILL BE DESIGNED SO THAT EVEN THE LEAST 
	SOPHISTICATED USER WILL FIND IT EASY TO USE THE MONITOR CORRECTLY.

1.3	DESIGN PHILOSOPHY

	THE DESIGN PHILOSOPHY FOR THE DISK MONITOR IS EMBODIED IN
	THE FOLLOWING PRINCIPLES.

	    1)  MODULARITY - THE DISK MONITOR WILL BE
	        DESIGNED AND IMPLEMENTED IN FUNCTIONALLY

		(AND LOGICALLY) INDEPENDENT PIECES (MODULES).

	    2)  FLEXIBILITY - THE DISK MONITOR WILL BE
	        DESIGNED TO ALLOW THE USER THE MAXIMUM
	        FLEXIBILITY IN DETERMINING HIS MONITOR
	        CONFIGURATION.  THIS WILL BE ACCOMPLISHED
	        BY DEVELOPING AN AUTOMATED SYSTEM GENERATION

	        PROCEDURE TO BE USED IN CONJUNCTION
		WITH THE MODULARITY DISCUSSED ABOVE.

	    3)  EXTENSIBILITY - THE DESIGN OF THE DISK
		MONITOR WILL ALLOW ANY MODULE TO BE CHANGED
		OR EXTENDED OR NEW MODULES TO BE ADDED WITH 
	 	VERY MINIMAL EFFECT ON OTHER MODULES OF THE SYSTEM.

	THE ABOVE PRINCIPLES WILL ALLOW THE USER OF THE DISK 
	MONITOR SYSTEM TO DETERMINE FOR HIMSELF THE RELATIVE
	IMPORTANCE OF EXECUTION SPEED VERSUS CORE-RESIDENT
	MONITOR SIZE AND MULTIPLE FEATURES VERSUS DISK-RESIDENT
	MONITOR SIZE.

	THE USER WILL BE ABLE TO CONFIGURE A SUBSET OF THE MONITOR
	TO BE USED AS A BASIC PROGRAM DEVELOPMENT MONITOR, OR HE
	MAY SELECT A FULL SCALE SINGLE USER MONITORING SYSTEM.
	THE INPUT/OUTPUT CONTROL WILL BE ACCOMPLISHED INSOFAR AS POSSIBLE
	BY "COMMON" CODE.  ALL DEVICE DEPENDENT FUNCTIONS WILL BE PERFORMED
	IN A MINIMAL DRIVER FOR EACH DEVICE.  THIS I/O ORGANIZATION HAS
	TWO REAL ADVANTAGES FOR THE USER; 1) OVERALL CORE SPACE REQUIRE-
	MENTS FOR THE MONITOR ARE CONSIDERABLY REDUCED AND 2) DEVICE
	INDEPENDENT USER CODE IS INSURED SINCE THE MONITOR ITSELF IS
	PROCESSING REQUESTS IN A DEVICE INDEPENDENT MANNER.

2.0	HARDWARE ENVIRONMENT

2.1	MINIMUM REQUIREMENTS

	THE MINIMUM CONFIGURATION REQUIRED TO RUN THE PDP-11 DISK
	MONITOR WILL BE
	
	     1 PDP-11/20 WITH 8K OF CORE

	     1 ASR-33 TELETYPE TERMINAL

	     1 RC11 64K FIXED HEAD DISK (DF32 TYPE)

	     2 DECTAPE DRIVES AND CONTROL.

	     1 DIODE ROM FOR BOOTSTRAP LOADING

	AS AN ALTERNATIVE MINIMUM CONFIGURATION THE MONITOR WILL ALLOW
	THE SUBSTITUTION OF A LARGER DISK FOR THE DECTAPES.   FOR THIS
	CONFIGUATION, HIGHSPEED PAPER TAPE WILL BE REQUIRED FOR
	(NOMINALLY) FAST LOADING OF THE DISK.  IN PLACE OF THE DISK
	AND DECTAPE DISCUSSED ABOVE THE FOLLOWING MAY BE SUBSTITUTED.

	     1 256K RF11 FIXED HEAD DISK
	     1 PC11 HIGH SPEED PAPER TAPE READER/PUNCH

	IT SHOULD BE NOTED THAT WITH THE ALTERNATE CONFIGURATION THE
	USER WILL EXPERIENCE CONSIDERABLE DIFFICULTY AND HEARTACHE
	WHENEVER HE IS REQUIRED TO LOAD THE SYSTEM FROM PAPER TAPE ONTO
	DISK DUE TO THE RELATIVELY LOW SPEED AND CUMBERSOME OPERATION
	OF THE PAPER TAPE READER.

	IN THE FUTURE MOVING HEAD DISKS WILL BE CONSIDERED FOR SYSTEM
	RESIDENCE.  IT IS NOT EXPECTED THAT "NORMAL" SYSTEM OPERATION
	WILL BE SIGNIFICANTLY DEGRADED BY THE USE OF THIS TYPE OF DEVICE.

2.2	HARDWARE OPTIONS

	IN ADDITION TO THE DEVICES MENTIONED IN THE MINIMUM CONFIGURATIONS
	DISCUSSED ABOVE THE DISK MONITOR WILL INITIALLY PROVIDE SUPPORT
	FOR THE FOLLOWING DEVICES.

	    ASR-33 TELETYPE TERMINAL
	    MULTIPLE DISKS OF EITHER KIND MENTIONED ABOVE.
	    MULTIPLE DECTAPES
	    PAPER TAPE READER/PUNCH (PC11)
	    LINE PRINTER.

2.3	FUTURE CONSIDERATIONS

	DUE TO THE MODULAR, FLEXIBLE STRUCTURE OF THE MONITOR,
	SUPPORT FOR ADDITIONAL DEVICES MAY BE ADDED TO THE MONITOR
	BY DEC OR BY A USER WITH NEGLIGIBLE CHANGE TO THE EXISTING
	MONITOR.  A SIMPLE, CONCISE SET OF GUIDELINES WILL BE
	PROVIDED TO FACILITATE THESE ADDITIONS.


3.0	SOFTWARE ENVIRONMENT

3.1	MINIMUM REQUIREMENTS

3.1.1	CO-RESIDENT SOFTWARE

	THE DISK MONITOR FOR THE PDP-11 IS BASED UPON A
	MINIMAL CORE-RESIDENT SUBSET.  THIS CORE RESIDENT NUCLEUS
	CONSISTS OF THE RESIDENT DISK DRIVER, COMMON EMT HANDLER
	AND THE TABLES AND VECTORS WHICH DRIVE THE MONITOR.  THE
	REQUIRED RESIDENT NUCLEUS WILL BE APPROXIMATELY 1K WORDS
	IN SIZE.

3.1.2	NON-CO-RESIDENT SOFTWARE

	THE DISK MONITOR IS INTENDED TO PROVIDE A SUPPORT FUNCTION
	FOR OTHER SYSTEM FUNCTIONS AND FOR USER FUNCTIONS.  IT
	PERFORMS ITS SERVICES ON A DEMAND BASIS.  MONITOR BUILDING
	(GENERATION) REQUIRES AN ASSEMBLER AND A LINKAGE EDITOR.

3.2	OPTIONS

	THE DISK MONITOR WILL BE THE BASIS FOR THE EXECUTION OF A WIDE
	VARIETY OF SOFTWARE INCLUDING ASSEMBLERS, COMPILERS,
	LINK EDITORS, REAL TIME/RUN TIME SYSTEMS, PIPS, ETC., AS
	WELL AS USER DEVELOPED SOFTWARE.

3.3	FUTURE CONSIDERATIONS

	EXTENSIONS AND IMPROVEMENTS TO THE DISK MONITOR SYSTEM 
	WILL BE EASILY ACCOMPLISHED BY ADDING MODULES OR RECODING
	OR CHANGING EXISTING MODULES.

	ADDITIONS TO THE SET OF SOFTWARE WHICH MAY RUN UNDER
	THIS SYSTEM CAN BE MADE EASILY BY MERELY FOLLOWING THE
	RULES FOR MONITOR CALLS (REQUESTS) WHICH ARE DISCUSSED
	IN SECTIONS 8 AND 6.

4.0	CONVENTIONS AND STANDARDS

	SINCE THE DISK MONITOR WILL BE BUILT USING AN ASSEMBLER
	AND A LINKAGE EDITOR, NO RESTRICTIONS NEED BY PLACED ON
	INTERNAL LABELLING.

	THE ONLY ROUTINE NAMING CONVENTION WHICH WILL BE ENFORCED
	WILL BE THE FOLLOWING:

	    ALL MONITOR ROUTINES WILL BE GIVEN THREE
	    LETTER NAMES.

(4.0 CONT'D)

	COMMUNICATION WITH THE MONITOR WILL BE ACCOMPLISHED IN THREE
	WAYS; (1) REQUEST FOR INPUT OR OUTPUT (I/O) SERVICE BY A
	RUNNING PROGRAM, (2) REQUEST FOR MONITOR SERVICE OTHER THAN
	I/O E.G. REQUEST FOR TIME OF DAY, OR (3) REQUEST FOR SERVICE
	BY THE (HUMAN) OPERATOR.  I/O REQUESTS WILL BE SIGNALED TO
	THE MONITOR BY THE USER ROUTINE THROUGH USE OF THE EMULATOR
	TRAP (EMT) INSTRUCTION.  SPECIFIC CALLING SEQUENCES ARE DE-
	FINED LATER (SECTION 8).  I/O CALLS USE EMT RATHER THAN I/O
	TRAP (IOT) TO SAVE SPACE FOR THE USER.  NON-I/O REQUESTS FROM
	AN OPERATING PROGRAM WILL ALSO BE SIGNALED THROUGH USE OF THE
	EMT INSTRUCTION.  AGAIN, SPECIFIC CALLING SEQUENCES WILL
	APPEAR LATER (SECTION 8).  THE OPERATOR WILL COMMUNICATE WITH
	THE MONITOR THROUGH USE OF THE TELETYPE KEYBOARD.  THE ACCEPT-
	ABLE KEYBOARD COMMANDS ARE DESCRIBED IN SECTION 8.  THE
	KEYBOARD COMMAND STRING MAY BE ACCEPTED FROM ANY INPUT 
	DEVICE.  THE OPERATOR MUST DESIGNATE THE DEVICE TO BE USED.

	SINCE SEVERAL TYPES OF SYSTEM PROGRAMS WILL COMMUNICATE
	WITH THE OPERATOR THROUGH USE OF THE KEYBOARD, THE FOLLOW-
	ING STANDARDS FOR DIALOGUE HAVE BEEN ESTABLISHED:

	A SINGLE CHARACTER WILL BE TYPED ON THE KEYBOARD TO INDICATE
	A REQUEST FOR INPUT.  THESE CHARACTERS ARE:

	$   THE DOLLAR SIGN INICATES A MONITOR REQUEST
	    FOR INPUT .  THE SYSTEM WILL BE IDLE UNTIL
	    SOME REPLY IS MADE.

	.   THE PERIOD IS TYPED BY THE MONITOR IN RESPONSE
	    TO ^C (CONTROL C) TYPED BY THE OPERATOR, I.E.
	    THE OPERATOR REQUEST THAT THE MONITOR ACCEPT
	    AN UNSOLICITED MESSAGE FROM HIM.  THE SYSTEM
	    WILL CONTINUE TO FUNCTION NORMALLY WHILE ACCEPTING
	    THE MESSAGE.

	>   THE GREATER THAN CHARACTER INDICATES THAT THE
	    COMMON COMMAND INTERPRETER REQUESTS AN
	    INPUT MESSAGE.

	*   THE ASTERISK INDICATES THAT SOME SYSTEM 
	    PROGRAM (ASSEMBLER, COMPILER, ETC.) REQUESTS
	    AN INPUT MESSAGE.

	ALL KEYBOARD INPUT MESSAGES WILL BE TERMINATED BY A 
	CARRIAGE RETURN.

	THE DEFINITIONS OF I/O FORMATS, CHARACTER SETS, AND
	FILE FORMATS WILL APPEAR IN THE FOLLOWING TWO SECTIONS.


5.0	FILE STRUCTURES FOR THE PDP-11 DISK MONITOR

	THE DISK MONITOR FILE STRUCTURE MODULE HAS THE FOLLOWING GOALS:

	A)  PRESENT A SINGLE STORAGE STRUCTURE TO SATISFY
	    THE REQUIREMENTS OF BOTH DISK AND DECTAPE.

	B)  NEARLY IDENTICAL PHYSICAL ORGANIZATION OF THE
	    RC11 AND RF11 DISKS.

	C)  HANDLE BOTH SEQUENTIAL AND RANDOM ACCESS FILES.

	D)  INTERLEAVE SEQUENTIAL FILES IN ORDER TO ACCOUNT
	    FOR MONITOR LATENCY.

	THE FILE STRUCTURE WILL CONSIST OF TWO TYPES OF DATA STRUCTURE:
	CONTIGUOUS AND LINKED.

	A)  A CONTIGUOUS DATA STRUCTURE CONSISTS OF AN AREA
	    OF PHYSICALLY CONTIGUOUS BLOCKS ON A BULK STORAGE
	    DEVICE.  THIS AREA MUST BE COMPLETELY ALLOCATED
	    PRIOR TO ITS USE.  ITS LENGTH MAY NOT BE CHANGED.

	B)  A LINKED DATA STRUCTURE CONSISTS OF A RANDOM SET
	    OF BLOCKS WITHIN WHICH AN ORDERING IS IMPLIED THROUGH
	    THE USE OF A LINK WORD IMBEDDED WITHIN EACH BLOCK.  A
	    LINKED FILE MAY BE DYNAMICALLY EXTENDED.

	THE DESCRIPTION OF THE FILE STRUCTURE ITSELF APPEARS IN
	THIS SECTION.  THE DESCRIPTION OF THE COMMANDS TO REFERENCE
	THE FILES APPEARS IN SECTION 8.



	A TWO LEVEL DIRECTORY (MASTER FILE DIRECTORY - MFD AND
	USER FILE DIRECTORY - UFD) WILL BE USED TO ENABLE SUPPORT
	OF MULTI-USER SYSTEMS.  THE STRUCTURE OF THE UFD FOR A FILE 
	WILL BE AS FOLLOWS:


			FILE I.D.
			  DATE
			  TYPE
			USAGE COUNT

			START BLOCK

			LENGTH OF
			FILE (# OF
			     BLOCKS)

			LAST BLOCK

			PROTECTION



	THE FILE DIRECTORY FORMAT WILL BE IDENTICAL FOR BOTH TYPES OF
	FILES.  A BIT IN THE FILE I.D. PORTION WILL INDICATE WHETHER THE
	FILE IS CONTIGUOUS OR LINKED.

	THE TRADE-OFF IMPLIED WITH HAVING THE TWO KINDS OF FILES IS THAT
	FILES THAT ARE PROCESSED SEQUENTIALLY (AS ASCII SOURCE FILES) DO
	NOT NEED RANDOM ACCESS; HOWEVER RANDOM ACCESS (CONTIGUOUS) FILES
	MAY WISH TO BE PROCESSED SEQUENTIALLY.

	CONTIGUOUS FILES ARE INTENDED FOR THE RANDOM ACCESS USER WHO USES
	.BLOCK AND .TRANS COMMANDS.  THEY ARE ALSO AVAILABLE FOR .DUMP
	TYPE OPERATIONS OR ANY OTHER SEQUENTIAL OPERATION WHERE THE FILE
	SIZE CAN BE DETERMINED PRIOR TO CREATING THE FILE.  ALTHOUGH .READ
	AND .WRITE COMMANDS TO CONTIGUOUS FILES ARE NOT ILLEGAL, THEY DO
	LOSE THE BENEFITS OF INTERLEAVING.

	LINKED FILES ARE INTENDED FOR THE SEQUENTIAL ACCESS USER WHO USES
	.READ AND .WRITE COMMANDS.  THEY ARE USED WHEN THE FILE SIZE IS
	NOT NECESSARILY KNOWN BEFORE THE FILE IS CREATED.  ALTHOUGH A
	.BLOCK COMMAND TO A LINKED TYPE FILE IS NOT ILLEGAL, THE USER IS
	DISCOURAGED FROM USING THIS SINCE THE OPERATION IS SO VERY SLOW.
	THE .BLOCK PROCESSOR WILL SEQUENTIALLY PASS THE FILE TO RETRIEVE
	BLOCK N AND READ FORWARD TO RETRIEVE BLOCK N+1.  HOWEVER, ACCESS TO
	BLOCK N-1 CAN ONLY RESULT IN THE READING OF ALL PREVIOUS BLOCKS.

	LATENCY (INTERLEAVING) WILL BE PROVIDED IN LINKED FILES BY ALWAYS
	ATTEMPTING TO ALLOCATE THE NEXT BLOCK IN THE SEQUENCE AT A FIXED
	DISTANCE FROM THE LAST BLOCK ALLOCATED.  INTERLEAVE FACTOR IS A
	DEVICE DEPENDENT CONSTANT.  CONSISTENT WITH SYSTEM PHILOS-
	OPHY, HOWEVER, WILL BE THE "HOOKS" FOR A USER DETERMINED INTERLEAVE
	FACTOR.



	ALLOCATION OF STORAGE AREA WILL BE BY THE BIT MAP METHOD.  A MASTER
	BIT MAP (ONE BIT DESCRIBING ONE BLOCK) WILL BE STORED ON THE DEVICE,
	AND WILL BE UPDATED UPON THE CLOSING ON THAT DEVICE OF ANY FILE THAT
	MAY HAVE ALTERED THE MAP.  THIS IS TRUE FOR ALL FILE STRUCTURED DE-
	VICES SUPPORTED BY THE DISK OPERATING SYSTEM.

	A TEMPORARY CORE RESIDENT MAP WILL DESCRIBE THE DEVICE FOR ALLOCA-
	TION PURPOSES.  IN ADDITION, DECTAPE WILL EMPLOY FILE BIT MAPS TO
	AID IN THE DELETION PROCESS.  WITH THIS STRUCTURE, THE CONCEPT OF
	A CORE BIT MAP IS REDUCED TO SIMPLY REFER TO THAT PORTION OF THE
	PERMANENT BIT MAP THAT HAPPENS TO BE IN CORE.  ALTHOUGH THE PROGRAM
	TO DO SO IS NOT PROVIDED, IT IS QUITE SIMPLE
	TO RECOVER THE ENTIRE DISK IN THE EVENT OF BIT MAP COR-
	RUPTION OR MONITOR FAILURE.

	.OPEN WILL BE RELATIVELY LENGTHY.
	.DELETE ON DISK WILL BE QUITE LENGTHY BECAUSE IT REQUIRES
	THE READING OF THE ENTIRE FILE AND CLEARING OF THE LINK WORDS.
	DECTAPE USERS AVOID THIS BY MEANS OF THE FILE BIT MAP AND THE COST
	OF ONLY ONE FILE AT A TIME OPEN FOR OUTPUT OR EXTENSION ON EACH
	TRANSPORT.  .CLOSE ON DECTAPE REQUIRES THE WRITING OF THE FILE BIT
	MAP AND DEVICE BIT MAP.  GARBAGE COLLECTION WILL BE VERY LONG SINCE
	IT REQUIRES A PROGRAM TO READ AND REWRITE THE WHOLE DEVICE.

	TO HELP PREVENT USER PROGRAMS FROM INADVERTENTLY DESTROYING ALL OR
	PART OF EXTERNAL STORAGE, EACH MONITOR SUPPORTED BULK STORAGE DEVICE WILL BE
	TREATED ONLY AS A FILE-ORIENTED DEVICE; ALL USER DATA RECORDED
	WILL BE RECORDED WITH A FILE NAME IN THE DIRECTORY.  SINCE THE
	MONITOR CANNOT GUARANTEE THE INTEGRITY OF BOTH FILE-STRUCTURED AND
	NON-FILE-STRUCTURED DATA ON THE SAME DEVICE, USERS OF THE .TRANS
	COMMAND ARE EXPECTED TO FIRST ALLOCATE A CONTIGUOUS FILE AND
	THEREBY, HOPEFULLY, PROTECT THE MONITOR AND OTHER USERS. THOSE
	USERS WHO DO INDEED ATTEMPT TO CIRCUMVENT THIS PROTECTION DO SO AT
	THEIR OWN PERIL. THIS, HOWEVER, DOES NOT
	NECESSARILY PRECLUDE PROGRAMMING A NON-FILE STRUCTURED DECTAPE
	HANDLER AND ASKING THE MONITOR TO DO I/O ON IT.

	WHEN THE SYSTEM IS INITIALLY LOADED ONTO THE SYSTEM DISK, THE
	MFD AND PERMANENT BIT MAP WILL CONTAIN THE ENTRIES CORRESPONDING
	TO THE MONITOR.



5.0.1	STORAGE STRUCTURES

	ALL USER FILES SUPPORTED BY THE MONITOR WILL BE OF ONE OR TWO
	TYPES:  CONTIGUOUS OR LINKED.

	EVERY USER FILE CONSISTS OF TWO SEPARATE ENTITIES:  THE 9 WORD
	DIRECTORY ENTRY AND THE FILE DATA.

5.1	FILE STRUCTURE

5.1.1	CONTIGUOUS FILE STRUCTURE

	RANDOM ACCESS FILE USERS AND DUMP FILE USERS WILL PRE-
	ALLOCATE AN AREA OF STORAGE EQUAL TO THEIR NEEDS.  TO
	CREATE A CONTIGUOUS FILE A USER WILL EITHER USE THE
	ALLOCATE FUNCTION OF PIP OR THE .ALLOC MONITOR CALL.
	ONCE ALLOCATED, A CONTIGUOUS FILE CANNOT BE EXTENDED OR
	APPENDED.  WHEN THE FILE IS
	OPEN FOR UPDATE OR INPUT THE USAGE COUNT FIELD OF THE
	DIRECTORY ENTRY IS INCREMENTED.  PHYSICALLY, A FILE WILL
	APPEAR AS BELOW, WITH ALL ITS DATA BLOCKS PHYSICALLY CON-
	TIGUOUS.  THE MAXIMUM SIZE OF A CONTIGUOUS FILE IS LIMITED
	TO 4 MILLION WORDS.







					FILE DATA






							"N" CONTIGUOUS BLOCKS
							AS INDICATED BY FILE
							ENTRY IN DIRECTORY



		UFD

		LINK


	UFD	FILE ID
	ENTRY
		 START

		FILE
		DESCRIPTORS

























		FIG. 1	UFD/CONTIGUOUS FILE RELATIONSHIP


5.1.2	LINKED FILE STRUCTURE

	SEQUENTIAL ACCESS FILE USERS NEED NOT BE CONCERNED WITH
	THE PHYSICAL PLACEMENT OF THEIR FILES ON THE DEVICE.
	THE MONITOR WILL ATTEMPT TO ALLOCATE EACH SUCCESSIVE
	BLOCK OF THE CHAIN SO AS TO RESOLVE THE LATENCY DUE TO
	THE MONITOR ITSELF - E.G. IN ACCORDANCE WITH THE INTER-
	LEAVE FACTOR.



				FILE DATA

					 LINK

					  D
					  A
					  T
					  A


					 LINK
		 UFD
					  D
		LINK			  A
					  T
					  A

	UFD	FILE ID
	ENTRY
		START			 LINK

		FILE
		DESCRIPTORS		  D
					  A
					  T
					  A


					   0

					  D
					  A
					  T
					  A









		FIG. 2	UFD/LINKED FILE RELATIONSHIP


5.2	DIRECTORY STRUCTURE

	THE DIRECTORY FILE IS A LINKED LIST TYPE FILE THAT CAN BE PROCESSED
	AS ANY USER LINKED FILE.  IT CONSISTS OF TWO PARTS: MASTER FILE
	DIRECTORY AND USER FILE DIRECTORY.  THE STARTING BLOCK OF THE MFD
	IS UNIQUE TO EACH DEVICE AND IS ENTERED AS A CONSTANT IN THE DE-
	VICE DRIVER.  NO METHOD IS PROPOSED TO PERMIT THE USE OF A DIFFER-
	ENT BLOCK IF THAT BLOCK ON THE DEVICE IS BAD.  THE MASTER FILE
	DIRECTORY, MFD, CONSISTS OF A DEVICE DEPENDENT NUMBER OF FOUR WORD
	ENTRIES AND A LINK TO THE NEXT BLOCK OF THE MFD CHAIN.  AS IN ALL
	LINKED LIST TYPE FILES, THE FIRST WORD OF EACH BLOCK IS EITHER A
	NULL LINK, INDICATING THE END OF THE CHAIN, OR, THE 16 BIT LINK
	TO THE NEXT BLOCK OF THE CHAIN.

	EACH MFD ENTRY IS OF THE FORM:


				UIC

			   UFD POINTER

			   # WDS/UFD ENTRY

				SPARE


	THE FIRST WORD OF EACH ENTRY IS THE UNIQUE 16 BIT USER IDENTIFI-
	CATION CODE, UIC.  THE HIGH ORDER BYTE WILL BE CONSIDERED THE
	USER GROUP; THE LOW ORDER BYTE WILL BE THE USER I.D.  THE SECOND
	WORD IS A POINTER TO THE ABSOLUTE STARTING BLOCK OF THIS PARTICU-
	LAR USER'S USER FILE DIRECTORY, UFD.  AS A HOOK FOR FUTURE IMPLE-
	MENTATIONS, THE THIRD WORD OF EACH MFD ENTRY HOLDS THE LENGTH OF
	EACH UFD ENTRY ASSOCIATED WITH THIS UIC.

	WHEN INITIALLY CREATED BY THE MONITOR'S SYSLOD PROGRAM THE
	MFD WILL CONTAIN ONLY THE UIC CODES OF CERTAIN "SPECIAL"
	USERS.  THE UFD POINTER WILL BE ZERO, INDICATING THAT THIS
	USER HAS NO UFD.  THE FIRST .OPENO OR .ALLOC CALL WILL
	RESULT IN THE ALLOCATION OF A BLOCK FOR THE UFD.  IT IS
	ASSUMED THAT A SPECIAL UTILITY PROGRAM WILL BE RUN IN ORDER
	TO ENTER A USER'S UIC ONTO THE MFD.



(5.2 CONT'D)

	SINCE THE FIRST BLOCK OF THE MFD MAY LIE IN A WRITE PROTECTED AREA,
	IT IS USED INSTEAD AS AN AREA TO HOLD DEVICE INFORMATION.  ITS
	FORMAT IS:


				LINK TO 2ND
				MFD BLOCK

				INTERLEAVE
				FACTOR

				BLOCK # OF
				1ST BIT MAP

				BLOCK # OF
				2ND BIT MAP

				BLOCK # OF
				3RD BIT MAP




				BLOCK # OF
				LAST BIT MAP

				    0












	EACH UFD DESCRIBES THE DATA FILES OF A PARTICULAR USER.  A UFD
	CONSISTS OF A LINKED LIST TYPE FILE; CURRENTLY EACH BLOCK OF THE FILE IS
	DIVIDED INTO A DEVICE DEPENDENT NUMBER OF 9-WORD FILE NAME EN-
	TRIES.  EACH ENTRY ENTIRELY DESCRIBES ONE USER FILE.


(5.2 CONT'D)


	(FROM
	DRIVER)




		FIRST MFD				UFD FOR USER A
		 BLOCK

		  LINK						0

		 POINTER	FILE		FILE	      FILE
				ID		ID	      ID
				ETC.		ETC.	      ETC.







		2ND MFD				UFD FOR USER B
		 BLOCK

		   0				 0
		 UIC A		FILE		FILE
		 POINTER	ID		ID






		 UIC B
		 POINTER
















		FIG. 3	MFD/UFD RELATIONSHIP



(5.2 CONT'D)

	AN INDIVIDUAL FILE ENTRY IN A UFD APPEARS AS FOLLOWS:

	WORD	0  FIL		6 CHARACTER FILE NAME PACKED MOD 40
		1  NAM
		2  EXT		3 CHARACTER FILE EXTENSION PACKED MOD 40
		3  T   DATE	TYPE/JULIAN CREATION DATE
		4  MODE,ETC	MODE/FILE LOCK BIT/USAGE COUNT
		5  START	ABSOLUTE STARTING BLOCK
		6  LENGTH	LENGTH OF FILE IN BLOCKS
		7  END		LAST BLOCK OF THE FILE
		8  SPARE  PRO	SPARE/PROTECT CODE

	EACH ENTRY ENTIRELY DESCRIBES A PARTICULAR USER FILE.  WORDS 0-2
	CONSTITUTE THE FILE ID.  THE LOW ORDER 12 BITS OF WORD 3 HOLD THE
	JULIAN CREATION DATE; THE HIGH ORDER 4 BITS ARE THE FILE TYPE.
	THE TYPE FIELD IS SET WHEN THE FILE IS FIRST ALLOCATED.


		TYPE	JULIAN DATE



	      15  12
	BITS 2  -2   = 0 ... LINKED FILE

		     =10 ... CONTIGUOUS FILE
		        (8)

	WORD 4 HOLDS THE LOCK BITS AND USAGE COUNT AS FOLLOWS:

				DATA MODE

		SPARE	  MODE	   LOCK  USAGE COUNT


(5.2 CONT'D)

	THE MODE FIELD DESCRIBE THE DATA MODE IN WHICH THE
	FILE WAS WRITTEN.  THOSE MODES WHICH HAVE BEEN DEFINED ARE:

		FORMATTED ASCII		- MODE = 0
		FORMATTED BINARY	- MODE = 1
		UNFORMATTED ASCII	- MODE = 2
		UNFORMATTED BINARY	- MODE = 3
		DUMP			- MODE = 4
		SEMI-FOMATTED ASCII	- MODE = 5

	(THE INCLUSION OF THE MODE IN THE DIRECTORY IS DEFINED; IT IS NOT
	IMPLEMENTED.)

	THE USAGE COUNT FIELD (BITS 2(0)-2(5)) DESCRIBES THE CURRENT STATE OF
	THE FILE.  FOR LINKED FILES, THE FIELD IS SET TO 77 WHEN THE FILE
	IS OPENED FOR OUTPUT VIA THE .OPENO COMMAND.  THE FILE CANNOT BE
	OPENED AGAIN UNTIL IT HAS BEEN CLOSED, THEREBY PREVENTING ANY AM-
	BIGUOUS OR CONFLICTING EVENT CONCERNING THIS FILE NAME (SUCH AS
	DELETING THE FILE WHEN IT IS OPEN FOR INPUT).  AFTER THE USAGE COUNT
	FIELD HAS BEEN SET TO 0 BY A .CLOSE COMMAND, IT IS INCREMENTED EVERY
	TIME A USER DOES A .OPENI TO THE FILE AND DECREMENTED EVERY TIME A
	.CLOSE IS DONE.  THE FILE MAY THUS BE OPEN TO AS MANY AS 62(10) USERS
	OR DATA SETS SIMULTANEOUSLY.

	WHEN A FILE IS OPENED FOR UPDATE OR EXTENSION, THE LOCK FIELD, BITS
	2(6)-2(7), IS SET TO 1, THEREBY ALLOWING SUBSEQUENT OPEN COMMANDS TO BE
	INPUT ONLY, AND LOCKING IT FROM FURTHER EXTENSION OR UPDATE.  THE
	LOCK FIELD IS CLEARED WHEN THE FILE IS SUBSEQUENTLY CLOSED.

	THE LOW ORDER BYTE OF WORD 8 DESCRIBES THE PROTECTION FEATURES
	WHICH THE FILE OWNER HAS ASCRIBED TO THIS FILE.  THE FORMAT OF THE
	BYTE IS:

		OWNER	USER GROUP  ALL OTHERS



(1.2 CONT'D)

	FILE PROTECTION IMPLIES LEVELS OF ACCESS.  THE OWNER OF A FILE
	ENJOYS THE HIGHEST ACCESS PRIVILEGE; HE CAN ACCESS HIS OWN FILE
	IN ANY MANNER HE CHOOSES (WRITE, DELETE, READ, ETC.).

	TO PREVENT INADVERTENT DELETION OR OVER-WRITING OF THE FILE,
	TWO SAFEGUARDS ARE BUILT IN:

		IF BIT 7=1 ... PROTECT THIS FILE FROM AUTOMATIC DELETION.
			       ON LOGOUT.

		OR,BIT 6=1 ... OWNER CANNOT WRITE UPON THIS FILE.

	ACCESS TO THE FILE BY USERS OTHER THAN THE OWNER IS DETERMINED
	BY THE ACCESS CODE ATTACHED TO THE FILE.
	THESE USERS ARE DIVIDED INTO TWO GROUPS - THE MEMBERS
	OF A USER GROUP, AND ALL OTHER USERS.  ABILITY TO ACCESS A FILE
	DEPENDS ON THE PROTECTION CODE ASSIGNED AND HOW THE USER WISHES
	TO OPEN THE FILE.  THE PROTECTION CODES THAT HAVE BEEN
	ASSIGNED ARE:

		0 = DELETE ACCESS PRIVILEGE
		1 = WRITE ACCESS PRIVILEGE
		3 = READ ACCESS PRIVILEGE
		5 = RUN ACCESS PRIVILEGE
		7 = NO ACCESS PRIVILEGE

	SHOULD A USER ATTEMPT TO ACCESS A FILE FOR AN ACCESS PRIVILEGE
	HIGHER THAN HE IS ASSIGNED, AN ERROR WILL RESULT.

	FOR INSTANCE, PROTECTION CODE 77 DENIES ALL ACCESS TO THIS FILE
	EXCEPT TO THE OWNER.  CODE 35 ALLOWS MEMBERS OF THE USER GROUP
	(FRIENDS) TO READ OR RUN THE FILE BUT NOT WRITE IT.  ALL OTHER
	USERS CAN RUN THE FILE, BUT NOT READ IT OR WRITE IT.

	IN GENERAL, TO SET THE PROTECTION FIELD THE FOLLOWING GUIDE LINES
	SHOULD BE FOLLOWED:

	    SET THE FIELD TO 0 TO ALLOW ANY GROUP MEMBER TO DO ANYTHING
	     "   "    "   "  1  "   "    "    "     "    "  WRITE OR READ YOUR FILE
	     "   "    "   "  3  "   "    "    "     "    "  READ YOUR FILE
	     "   "    "   "  7  " PREVENT ACCESS TO THEIR FILE BY ALL GROUP MEMBERS



5.3	DEVICE LAYOUT

	EACH DIRECT ACCESS STORAGE DEVICE SUPPORTED BY THE MONITOR
	HAS ONLY ONE LEVEL OF ALLOCATION - THE BLOCK.  BLOCK SIZE
	IS A DEVICE DEPENDENT FUNCTION:

		RC11 DISK .. 64 WORDS/BLOCK
		RF11 DISK ... 64 WORDS/BLOCK
		RK11 DISK ... 128 OR 256 WORDS/BLOCK
		DECTAPE   ... 256 WORDS/BLOCK

	CLUSTERING, GROUP ALLOCATION AND FILE INDICES WERE ALL CON-
	SIDERED AND DISCARDED AS BEING TOO COSTLY IN TERMS OF STORAGE
	AREA AND CORE REQUIREMENTS.

5.3.1	FIXED HEAD DISK

	THE SMALL (64K RC11) AND LARGE (256K RF11) DISKS WILL
	DIFFER ONLY IN BIT MAP SIZE.  FOR ALLOCATION PURPOSES,
	THE LARGE DISK IS CONSIDERED AS FOUR CONTIGUOUS SMALL DISKS
	OF 1024 BLOCKS OF 64 WORDS EACH.  THIS SAME IDEA WILL
	BE EXTENDED TO MULTIPLE PLATTERS ON THE SAME CONTROLLER,
	E.G. FOUR RC11 DISKS APPEAR TO THE MONITOR AS ONE RF11
	DISK.

	NO ATTEMPT WILL BE MADE TO EXTEND FILES ACROSS CONTROLLERS.


(5.3.1 CONT'D)

	THE FOLLOWING DIAGRAM, FIG. 4, PORTRAYS THE LAYOUT OF A FIXED
	HEAD DISK.  BLOCK 1 WILL HOLD THE FIRST BLOCK OF THE MFD AS
	DESCRIBED EARLIER.  AT SYSGEN TIME THE BIT MAPS AND THE SECOND
	BLOCK OF THE MFD WILL BE DETERMINED.  THE MONITOR WILL ALWAYS
	ATTEMPT TO ALLOCATE CONTIGUOUS FILES FROM THE HIGH END OF THE
	DEVICE, AND LINKED FILES FROM THE LOW END.


	BLOCK 0		SYSTEM BOOT

	BLOCK 1		FIRST MFD BLOCK

	BLOCK 2


			  SYSTEM FILES

	(HARDWARE
	PROTECT LINE)


			USER LINKED FILES




			USER CONTIGUOUS
			    FILES

	LAST BLOCK	   BIT MAPS






















		FIG. 4	FIXED HEAD DISK



5.3.2	DECTAPE LAYOUT

	DECTAPE IS DIVIDED INTO 576 PHYSICAL BLOCKS OF 256 WORDS
	EACH.  BECAUSE OF THE PROBLEMS ASSOCIATED WITH DELETING
	AND CLOSING SEQUENTIAL FILES ON DECTAPE, FILE MANAGEMENT
	WILL ENTAIL THE KEEPING OF FILE BIT MAPS.

	SINCE 36 WORDS OF FILE BIT MAP WILL COMPLETELY DESCRIBE
	A DECTAPE, EACH DECTAPE BLOCK WILL HOLD 7 FILE BIT MAPS.
	THE DIRECTORY INFORMATION FOR 28 FILES CAN BE HELD IN
	ONE BLOCK, THE FIRST ENTRY CORRESPONDING TO THE FIRST
	FILE BIT MAP.  EACH DECTAPE, THEN, WILL SUPPORT 56 USER
	FILES (8 BLOCKS OF FILE BIT MAP AND 2 BLOCKS OF UFD).

	DECTAPE USERS ARE RESTRICTED TO A SINGLE OUTPUT FILE PER
	DECTAPE AT ANY ONE TIME.  THIS IS NECESSARY FOR EFFICIENT
	IMPLEMENTATION OF FILE BIT MAPS.  IT IS FELT THAT THE
	SPEED GAINED IN CLOSING AN OUTPUT FILE IS A DESIRABLE
	TRADE-OFF.



(5.3.2 CONT'D)


	BLOCK 0			SYSTEM BOOT






				USER FILES






	BLOCKS 70-77		FILE BIT MAPS




	BLOCKS 100-101(8)	    MFD


	BLOCKS 102-103(8)	    UFD


	BLOCK 104		PERMANENT BIT MAP






				   USER FILES


















			FIG. 5	DECTAPE LAYOUT



5.3.3	CARTRIDGE TYPE DISK

	NOT YET DETERMINED


5.4	BIT MAPS

	THE PERMANENT BIT MAP, PBM, REPRESENTS THE STATE OF EACH BLOCK OF
	THE MASS STORAGE DEVICE, OCCUPIED OR FREE.  A BIT IN THE MAP IS
	ASSIGNED TO EACH BLOCK ON THE DEVICE, RELIEVING THE PROBLEM OF
	LARGE LOSSES DUE TO INABILITY TO REALLOCATE THE UNUSED PORTIONS
	OF MULTI-BLOCK OR CLUSTER TYPE ALLOCATIONS.  THE AVERAGE WASTAGE
	PER FILE IS LIMITED, THEN, TO ONE HALF THE BLOCK SIZE.

	THE ASSIGNMENT OF ONE BIT PER BLOCK, HOWEVER, CREATES THE
	NECESSITY OF MULTIPLE BIT MAPS TO ACCOMMODATE THE ENTIRE MAP.
	THE MULTIPLE MAP IS ATTRACTIVE, THOUGH, BECAUSE OF ITS PROPER-
	TIES:

	1)  ALLOWS 1 BIT/BLOCK, THEREBY REDUCING WASTAGE

	2)  ENABLES THE FILE MANAGER TO RESTRICT OPERATIONS
	    TO A SINGLE AREA OF THE DEVICE.  THIS IS PARTIC-
	    ULARLY APPROPRIATE FOR MOVING HEAD DISK.

	3)  SIMPLIFIES CONTROL OF INTERLEAVING

	4)  SIMPLIFIES CONTROL OF ALLOCATION


(5.4 CONT'D)

	THE FORMAT FOR ALL BIT MAPS IS THE SAME:


			LINK TO NEXT MAP	WORD 0

			MAP NUMBER		     1

			MAP SIZE		     2

			LINK TO FIRST MAP	     4








				 BIT
				MAP







						WORD N



	THE NUMBERING OF BITS IN THE MAP IS FROM RIGHT TO LEFT, WHEN A
	WORD AND A BIT DESCRIBE A BLOCK.  TO CONVERT A BLOCK NUMBER TO A
	BIT IN THE MAP, THE FOLLOWING ALGORITHM HOLDS:

			WORD NUMBER = BLOCK/16

			BIT NUMBER  = REMAINDER


(5.4 CONT'D)

	THE SIZE OF THE BIT MAP FOR ALL DISKS IS 60 WORDS OF MAP AND 4
	WORDS OF HEADER.

	THE BITS OF A MAP DESCRIBING NON-EXISTENT BLOCKS ARE SET TO
	OCCUPIED AT SYSGEN TIME.

	FOR RC11 DISK, BIT MAP 0 REFERS TO BLOCKS 0-959
			"   "  1   "    "    "    960-1023

	FOR RF11 DISK, BIT MAP 0 REFERS TO BLOCKS 0-959
			"   "  1   "    "    "    960-1919
			"   "  2   "    "    "    1920-2879
			"   "  3   "    "    "    2880-3839
			"   "  4   "    "    "    3840-4095


	THE DECTAPE BIT MAP IS 36 WORDS LONG.  THE BITS DESCRIBING BLOCKS
	0, 74-104, AND 575 ARE ALWAYS SET TO OCCUPIED.

	WHEN A LINKED FILE IS INITIALLY CREATED, THE FILE MANAGER WILL
	ALLOCATE A BLOCK TO THE FILE BY SETTING THE APPROPRIATE BIT IN
	THE PBM TO "OCCUPIED".  THEREAFTER, WHENEVER A NEW BLOCK IS
	NEEDED FOR FILE RECORDING, THE FILE MANAGER ALLOCATES A BLOCK
	TO THE FILE, SETS THE APPROPRIATE BIT IN THE PBM AND LINKS THE 
	BLOCK TO THE PREVIOUS BLOCK IN THE CHAIN.

	WHEN A FILE IS DELETED THE BITS IN THE PBM CORRESPONDING TO THAT
	FILE ARE CLEARED.  TO AID IN THE DECTAPE FILE DELETION PROCESS,
	A FILE BIT MAP IS CREATED WHEN THE FILE IS CREATED.

	SINCE THE PERMANENT BIT MAP CAN BE RE-CREATED AT ANY TIME, ITS
	IMPORTANCE DIMINISHES WHEN COMPARED TO ITS USAGE IN OTHER
	SYSTEMS. THE "CURRENT" BIT MAP OR CORE BIT MAP WILL SIMPLY BE
	THAT PORTION OF THE PBM THAT HAPPENS TO BE IN CORE.  THE BIT
	MAP IS USED ONLY TO KEEP TRACK OF THE CURRENT STATE OF THE
	DEVICE.




5.5	INTERLEAVING

	THE OPTIMUM INTERLEAVE FACTOR OF ALL DEVICES CONSIDERED TO DATE
	IS 4, THAT IS, 3 UNALLOCATED BLOCKS BETWEEN EACH ALLOCATED BLOCK.

	FOR DISK, INTERLEAVING FACTOR IS A FUNCTION OF BLOCK SIZE, THE
	NUMBER OF BLOCKS PER TRACK, AND SPEED OF ROTATION.  IT REFLECTS
	THE LENGTH OF TIME THE MONITOR TAKES TO PASS A BLOCK TO THE
	USER AND HOW MANY BLOCKS HAVE PASSED UNDER THE HEADS DURING THAT
	TIME.

	THE INTERLEAVING FACTOR FOR DECTAPE IS 4 BECAUSE OF HARDWARE
	CONSIDERATIONS:

	    STOP TIME = 40 MS (1 BLOCK)
	    START-UP TIME = 120 MS (2 BLOCKS)

	IN THE EXAMPLE BELOW, ASSUME THE USER OF A LOGICALLY SEQUENTIALLY
	FILE HAS JUST PROCESSED BLOCK 0.  THE DECTAPE WILL STOP AT (A)
	BETWEEN BLOCKS 1 AND 2; SINCE START-UP TIME IS TWO BLOCKS, THE
	NEXT BLOCK THAT CAN BE PROCESSED IS BLOCK 4, GIVING AN INTER-
	LEAVE FACTOR OF 4.

		0	1      2    3     4     5      6

	    PROCESS   STOP     START     PROCESS

		           A
			              B



	NO PROVISION IS MADE OR CONTEMPLATED TO HANDLE MORE THAN
	ONE INTERLEAVE FACTOR PER DEVICE.

	AUTOMATIC DISK ALLOCATION INVOLVES SEARCHING THE PBM FOR AN
	UNOCCUPIED BLOCK.  IF FOUND, THE APPROPRIATE BIT IS SET TO
	"OCCUPIED" AND THE BLOCK LINKED INTO THE CHAIN. IF NOT FOUND,
	A SYSTEM ERROR INDICATING DISK FULL WILL RESULT.

	NOTE THAT ONLY 64 WORDS OF PERMANENT BIT MAP ARE EVER IN CORE
	AT ONE TIME.  THOSE SYSTEMS WITH MORE THAN ONE MAP PER DEVICE
	WILL REQUIRE, OBVIOUSLY, THE WRITING OF THE CURRENT MAP AND
	READING ANOTHER.  IN ORDER TO KEEP AS MUCH SPACE AS POSSIBLE
	FOR CONTIGUOUS FILES, THE LOW NUMBERED BLOCKS WILL BE ALLOCATED
	FIRST.
1K FIRST.

	AUTOMATIC DECTAPE ALLOCATION DIFERS FROM DISK.  ALLOCATION
	CONTINUES IN THE CURRENT DIRECTION UNTIL BLOCKS IN THAT
	DIRECTION HAVE BEEN ALLOCATED.  THE DIRECTION OF TRAVEL IS
	THEN REVERSED - E.G. GO AS FAR AS POSSIBLE IN ONE DIRECTION
	AND THEN TURN AROUND.


5.6	ALLOCATION OF STORAGE AREA

	THE MONITOR SUPPORTS THE NEEDS OF TWO KINDS OF FILES:
	PHYSICALLY CONTIGUOUS AND LINKED SEQUENTIAL (INTERLEAVED).
	THE TYPE OF FILE IS INDICATED IN THE TYPE FIELD OF THE
	DIRECTORY ENTRY.

	ALLOCATION OF DISK OR DECTAPE AREA IS ACCOMPLISHED BY TWO
	MEANS:

	   BY MONITOR CALL OR BY KEYBOARD REQUEST THROUGH
	   PIP FOR A CONTIGUOUS STORAGE AREA, OR

	   AUTOMATICALLY BY THE FILE MANAGER FOR A LINKED
	   AREA.

	WHEN THE USER REQUESTS THE ALLOCATION OF N CONTIGUOUS
	BLOCKS, THE BLOCK ALLOCATOR BEGINS SCANNING THE PBM FROM
	THE END, LOOKING FOR THE APPROPRIATE NUMBER OF UNOCCUPIED
	BLOCKS ("REMEMBERING" THE LARGEST AREA IT FINDS).  IF N
	CONTIGUOUS BLOCKS ARE FOUND, THE CORRESPONDING BITS ARE
	SET IN THE PBM, AND AN ENTRY IS MADE IN THE UFD FOR THIS
	FILE.  THE FILE IS THUS CREATED.  THE USER MAY THEN OPEN
	THE FILE FOR UPDATE OR INPUT.

	IF THE BLOCKS ARE UNAVAILABLE, THE USER HAS THREE OPTIONS:

	   DELETING UNNEEDED FILES IN THE HOPE OF CREATING
	   THE REQUIRED SIZE HOLE, OR

	   RUNNING THE GARBAGE COLLECTION PROGRAM, OR

	   ACCEPTING THE LARGEST SIZE AREA THAT IS AVAILABLE.

6.0	INPUT-OUTPUT WITHIN THE PDP-11 DISK MONITOR

6.1	INTRODUCTION

	THE PURPOSE OF THIS SECTION IS TO OUTLINE THE METHOD BY
	WHICH THE PDP-11 USER WILL OBTAIN MONITOR ASSISTANCE IN THE
	HANDLING OF I/O TRANSFERS.

	THE DESIGN GOALS ARE DEFINED AND DESCRIPTIONS GIVEN
	FOR THE OVERALL STRATEGY TO MEET THESE GOALS.

6.2	AIMS

	THE PRINCIPAL OBJECTIVES ARE TO PROVIDE THE FOLLOWING 
	FACILITIES:

	A)  STANDARD SUBROUTINES FOR BASIC HANDLING OF I/O
	    DEVICES.

	B)  FILE MANIPULATION ON BULK-STORAGE MEDIA.

	C)  DEVICE INDEPENDENCE TO THE EXTENT THAT PHYSICAL
	    DEVICES NEED NOT BE KNOWN UNTIL THE PROGRAM
	    IS READY FOR EXECUTION.

	D)  COMPATIBILITY WITH PREVIOUSLY SUPPLIED DEC
	    PDP-11 I/O SOFTWARE (IOX).

	E)  MODULAR I/O STRUCTURE ORGANIZED SO THAT A MAXIMUM
	    PORTION OF ALL PROCESSING IS PERFORMED IN DEVICE
	    INDENDENT COMMON I/O ROUTINES WITH ALL (AND
	    ONLY) DEVICE DEPENDENT FUNCTIONS BEING PERFORMED
	    IN A VERY MINIMAL DEVICE DRIVER.


	THESE OBJECTIVES MUST, OF COURSE, BE ATTAINED WITH THE LEAST
	PENALTY TO THE USER BOTH FROM THE POINT OF VIEW OF THE
	MEMORY CAPACITY COST, TO THE I/O SERVICING ROUTINES AND
	OF THE TIME TAKEN TO SATISFY A TRANSFER REQUEST.

6.3	STRATEGY
	
6.3.1	DATA SETS
	
	THE USER WILL CONSIDER ALL I-O AS TRANSFERS TO OR
	FROM "DATA-SETS", WHERE A DATA-SET IS DEFINED TO BE
	ONE OF THE FOLLOWING, DEPENDING ON USAGE:

	A)  ALL THE INPUT OR OUTPUT OF A SINGLE-FILE DEVICE 
	    SUCH AS A PAPER TAPE READER OR LINE PRINTER;

	B)  AN INDIVIDUAL FILE WITHIN THE LIBRARY OF A 
	    BULK STORAGE DEVICE SUCH AS A DISK OR MAGNETIC TAPE;

	C)  THE COMPLETE DISK OR MAGNETIC TAPE IF USED
	    IN A NON-FILE-ORIENTED MODE.

	BY AN APPROPRIATE CALL TO THE MONITOR, THE USER MAY DEMAND
	OR SUPPLY VARIABLE-LENGTH LINES OF INFORMATION WITHIN THE
	DATA-SET AND MAY SPECIFY THAT THESE BE IN A PARTICULAR MODE,
	E.G. ASCII OR BINARY, FORMATTED OR UNFORMATTED.  WHERE THE
	DATA-SET IS IN FACT ONE OF SEVERAL FILES ON A BULK STORAGE
	DEVICE, HE WILL ALSO BE ABLE TO IDENTIFY THE ONE REQUIRED
	BY NAME.

6.3.2	COMMON I/O ROUTINES


	TO RESTRICT MONITOR CORE USAGE, EACH USER REQUEST WILL BE
	SATISFIED AS FAR AS POSSIBLE BY COMMON REENTRANT CODE, E.G.
	THEY WILL BE A COMMON READ PROCESSOR.  THIS WILL DEPEND
	UPON EACH I/O DEVICE APPEARING ALIKE TO THE PROCESSING
	ROUTINES.  ALL DEVICES WILL THEREFORE BE ASKED TO OPERATE
	UPON BLOCKS OF INFORMATION OF A SIZE APPROPRIATE TO EACH.
	THE DRIVING ROUTINES WILL CONTAIN ONLY THOSE SEQUENCES 
	WHICH THEY MUST UNIQUELY PROVIDE TO EFFECT THIS.

	THE COMMON PROCESSING ROUTINES WILL THEN BE RESPONSIBLE
	FOR TRANSFERRING THE DATA BETWWEEN THE DEVICE BLOCK AND THE
	USER LINE, MEETING ANY SPECIFICATIONS FOR CHARACTERS, PARITY
	OR SUM CHECKING.  THEY WILL ALSO MAINTAIN THE NECESSARY IDEN-
	TIFYING INFORMATION FOR EACH DATA-SET.

6.3.3	CORE ECONOMIZING MEASURES

	FURTHER CORE ECONOMY MAY BE OBTAINED IN THE FOLLOWING WAYS:

	A)  BUFFERS FOR DEVICE BLOCK TRANSFERS WILL BE CLAIMED
	    FROM AND RELEASED TO FREE CORE.

	B)  DEVICE HANDLING ROUTINES MAY BE CORE RESIDENT
	    ONLY FOR AS LONG AS THE USER REQUIRES THEIR PRESENCE.


6.3.4	INTERMEDIATE BUFFERING

	INTERMEDIATE BUFFERING WILL OCCUR FOR ALL I/O DEVICES.
	THIS BUFFERING REQUIRES THAT ALL I/O DATA BE MOVED FROM THE
	MONITOR BUFFER TO THE USER'S BUFFER DURING DEBLOCKING.
	BECAUSE THE TIME REQUIRED FOR THIS MOVING MAY BE PROHIBITIVE
	FOR SOME APPLICATIONS, TWO MORE DIRECT ACCESS METHODS
	(BLOCK AND TRANS, DISCUSSED BELOW) ARE PROVIDED.  SINCE
	THE INTERMEDIATE BUFFERING PROVIDES, IN EFFECT, DOUBLE
	BUFFERING (USER BUFFER AND MONITOR BUFFER), THE MONITOR
	WILL NOT USURP THE SPACE REQUIRED FOR TRUE DOUBLE BUFFERING
	THE USER MAY DOUBLE BUFFER HIS LINE BUFFERS, HOWEVER, IF HE
	WISHES TO SPEED UP HIS I/O ACTIVITY.

	THE FOLLOWING FEATURES WILL BE INCLUDED IN ORDER TO KEEP
	THE TIME COST TO THE USER TO A MINIMUM:

	A)  IN ORDER THAT THE PROCESSING ROUTINES MAY
	    SATISFY A USER LINE REQUEST FROM DATA ALREADY
	    IN CORE, DEVICE BLOCKS WILL BE REFILLED OR 
	    EMPTIED IMMEDIATELY EVEN IF THE USER'S CURRENT
	    REQUIREMENT HAS BEEN SATISFIED.

	B)  ACTUAL I/O OPERATIONS WILL FULLY UTILIZE THE
	    HARDWARE INTERRUPT FACILITY SO THAT THE USER MAY
	    CONCURRENTLY CONTINUE PROCESSING FOR AS LONG AS
	    THIS PRACTICAL.

	SUCH A SYSTEM WILL NATURALLY CAUSE TIMING CONFLICTS
	WITHIN THE MONITOR.  THESE WILL BE RESOLVED ACCORDING
	TO THE FOLLOWING PRINCIPLES:

	A)  ALTHOUGH A DEVICE DRIVING ROUTINE MAY BE CAPABLE
	    OF SERVICING SEVERAL DATA SETS, IT CAN ONLY PERFORM
	    ONE TASK AT A TIME.  MULTIPLE REQUESTS WILL BE
	    QUEUED AND HONORED, IN PRIORITY SEQUENCE IF NEED BE.

	B)  DYNAMIC BUFFER ALLOCATION WILL BE DEPENDENT
	    UPON THE AVAILABILITY OF FREE CORE.

	C)  OPERATIONS ON ONE DATA-SET MUST BE CARRIED OUT
	    SEQUENTIALLY.  ANY USER REQUEST FOR FURTHER
	    ACTION BEFORE COMPLETION OF A PREVIOUS ONE WILL
	    THEREFORE RESULT IN A HOLD-UP IN PROCESSING.  THE
	    USER, HOWEVER, WILL BE GIVEN THE OPPORTUNITY TO
	    SPECIFY AN ALTERNATIVE COURSE OF ACTION IN THIS SITUATION.


6.4	PROCEDURES

6.4.1	I/O CALLS TO MONITOR

	ALL I/O CALLS TO THE MONITOR ROUTINES WILL BE BY WAY OF THE
	EMT INSTRUCTION WITH THE PROPER CODE AND AN ARGUMENT STRING
	TO SHOW THE DATA-SET REQUIRED.  THE STRING MAY ALSO INCLUDE
	OPTIONAL QUALIFYING PARAMETERS APPROPRIATE TO EACH FUNCTION.
	A LIST OF THE FUNCTIONS SHOWING THEIR PURPOSE AND ARGUMENTS
	IS FOUND IN SECTION 8.4.

	ALTHOUGH A SYMBOLIC LANGUAGE PROGRAM MAY ALWAYS BE WRITTEN
	TO INCLUDE THE BASIC CALLING SEQUENCES, IT IS ASSUMED THAT
	STANDARD MACROS WILL BE AVAILABLE WITHIN ANY HIGH-LEVEL
	ASSEMBLER.  IT IS ALSO EXPECTED THAT COMPILER LANGUAGES WILL
	PRODUCE THE SAME SEQUENCES EITHER DIRECTLY FOR FUNCTIONS
	NORMALLY PART OF THEIR SYNTAX OR THROUGH CALLS TO LIBRARY
	SUBROUTINES.


6.4.2	DATA-SET IDENTIFICATION

	IN HIS SOURCE PROGRAM, THE USER MUST SET UP, IN THE FOLLOWING
	FORMAT, A LINK BLOCK FOR EACH OF THE DATA-SETS HE WILL BE USING: 


		ERROR RETURN ADDRESS OR 0 (NO BUFFER RETURNED)

	LABEL:  0 (RESERVED FOR MONITOR USE--DDB POINTER

		LOGICAL DATASET NAME (PACKED MOD 40)

		UNIT NUMBER          0=NO DEVICE SPECIFIED
				     1=DEVICE SPECIFIED

		3 CHARACTER DEVICE NAME IF SPECIFIED
			(PACKED MOD 40)


	IN SYMBOLIC LANGUAGES HE WILL USE THE ADDRESS OF THIS BLOCK TO
	IDENTIFY THE DATA-SET WHEN REQUESTING ANY I/O FUNCTION, E.G.
	INIT LABEL,.... . HIGHER LEVEL LANGUAGES SUCH AS FORTRAN,
	IN WHICH IT IS CUSTOMARY TO DESIGNATE LOGICAL DEVICES BY
	NUMBER, WILL SET UP THE LINK-BLOCK ON THE USER'S BEHALF AND
	CONVERT SUCH NUMBER TO A SYMBOL EQUIVALENT TO A DEVICE NAME BY
	CONVENTION.  THE LABEL OF THE LINK-BLOCK MAY, OF COURSE,
	BE USED AS A GLOBAL REFERENCE IN A MULTI-SEGMENT PROGRAM.

(6.4.2 CONT'D)

	BEFORE USING A DATA-SET, THE USER MUST INITIALIZE IT VIA AN
	INIT CALL.  THE CORRESPONDING MONITOR FUNCTION WILL FIRST
	ESTABLISH A DATASET DATA BLOCK (D.D.B.) FOR THE DATA-SET
	IN FREE CORE AND PLACE ITS STARTING ADDRESS IN THE FIRST WORD
	OF THE LINK BLOCK.  THIS D.D.B. WILL BE USED THROUGHOUT TO
	STORE DETAILS OF THE CURRENT STATE OF OPERATIONS UPON THE
	DATA-SET AND WILL HAVE A FORMAT AS FOLLOWS:


		MONITOR CHAIN FIELD

		DRIVER QUEUE FIELD

		DRIVER LINK AND PRIORITY

		DRIVER ADDRESS

	   DDB:	BUSY FLAG; 0=FREE

		USER BUFFER ADDRESS

		DEVICE BLOCK NUMBER

		MEMORY ADDRESS FOR
		   TRANSFER

		   WORD COUNT

		UNIT/FUNCTION (SEE BELOW)

		COMPLETION RETURN ADDRESS

		TRANSFER INCOMPLETE FLAG
		(CONTAINS INCOMPLETE COUNT)

		BYTE COUNT  (READ/WRITE)

		CHECKSUM    (READ/WRITE)

		DEVICE ASSIGNMENT POINTER

		  FIB   POINTER


	THE UNIT/FUNCTION WORD HAS THE FOLLOWING FORMAT

		BIT	INTERPRETATION
		0	0=ASCII, 1=BINARY
		1	WRITE IF ON
		2	READ IF ON
		3	RESERVED
		4-5	EXTENDED MEMORY
		6	SPARE
		7	OPEN FLAG
		8-10	UNIT
		11	DECTAPE REVERSE
		12	SPARE
		13	EOF ENCOUNTERED
		14	EOM ENCOUNTERED
		15	DEVICE PARITY


(6.4.2 CONT'D)

	THE INIT PROCESSOR WILL THEN COLLECT FROM THE LINK BLOCK
	THE NAME OF THE DEVICE HANDLER REQUIRED TO SERVICE THE
	DATA-SET AND ALSO THE UNIT NUMBER OF SUCH DEVICE.  IF
	THIS HANDLER IS NOT ALREADY IN MEMORY FOR ANOTHER DATA-
	SET, THE MONITOR ROUTINE WILL LOAD IT INTO A FREE CORE
	BUFFER AND PLACE ITS STARTING ADDRESS AND THE UNIT NUMBER
	INTO THE DDB.  FOR SUBSEQUENT OPERATIONS, THE DDB WILL THUS
	FORM THE LINK BETWEEN THE USER PROGRAM, THE MONITOR ROUTINES
	AND THE HANDLER.  THE CORE SPACE IT OCCUPIES WILL BE SURREND-
	ERED TO FREE CORE WHEN THE USER PROGRAM ISSUES A RELEASE.

	WHEN A DATA-SET IS ACTUALLY A FILE ON BULK STORAGE, FURTHER
	IDENTIFICATION WILL BE NEEDED.  THE USER WILL SUPPLY THIS THROUGH
	AN OPEN CALL.  IN THIS CASE, THE MONITOR ROUTINE WILL CHECK
	WHETHER THE DEVICE IS IN FACT BULK-STORAGE.  IF SO, A FILE
	INFORMATION BLOCK (FIB) WILL BE SET UP IN A FREE-CORE BUFFER
	AND ITS ADDRESS ENTERED IN THE DDB.

	THE DETAIL IN THIS BLOCK WILL THEN BE AVAILABLE FOR USE
	BY MONITOR FILE MANIPULATION ROUTINES.  THE BLOCK WILL BE
	RETURNED TO FREE CORE WHEN THE USER PROGRAM CALLS CLOSE.
	SHOULD THE USER WISH TO OPEN A NEW FILE UNDER THE SAME
	LOGICAL NAME, HE MAY DO SO BY ISSUING A NEW OPEN WITH SIMILAR
	EFFECT TO THAT DESCRIBED.

	IN CALLING THE FILE MANAGER, TWO ARGUMENTS ARE USUALLY PASSED -
	THE LINK BLOCK ADDRESS (DISCUSSED ABOVE) AND THE FILE NAME BLOCK.
	THE FILENAME BLOCK FOR FILE STRUCTURED OPERATIONS CONSISTS OF 
	SEVEN WORDS OF INFORMATION DESCRIBING THE FILE TO BE OPERATED
	UPON.  ITS FORMAT IS:

		ERROR RETURN ADDRESS

		ERROR RETURN CODE/HOW OPEN CODE

	FILBLK:	FILE (PACKED MOD 40)

		NAME (PACKED MOD 40)

		EXT (PACKED MOD 40)

		USER IDENTIFICATION CODE

		PROTECT CODE

	THE GENERAL SIGNIFICANCE OF EACH ITEM IS OUTLINED BELOW.  ITS
	SPECIFIC SIGNIFICANCE FOR FILE-STRUCTURED DEVICES IS DESCRIBED
	IN DETAIL IN SECTION 5.

	ERROR RETURN ADDRESS:-  CONTROL WILL BE RETURNED TO THE USER
	PROGRAM AT THIS ADDRESS UPON RECOGNITION OF A PROGRAMMABLE
	ERROR.  IF NO ADDRESS IS GIVEN, THE ERROR WILL BE TREATED AS
	FATAL, RESULTING IN A DIAGNOSTIC MESSAGE.

	ERROR STATUS BYTE:-  THE OPEN PROCESSOR WILL INDICATE THE
	NATURE OF THE ERROR BY A CODE (SEE BELOW)

	TYPE OF OPEN BYTE:-  THE USER MUST SHOW THE INTENDED USAGE OF
	THE DATASET BY A CODE.  CURRENTLY THIS MAY BY ONE OF FIVE
	VALUES AS FOLLOWS:

	1-  OPEN AN EXISTING FILE FOR UPDATE (OPENU)

	    THIS IMPLIES BOTH INPUT AND OUTPUT CAPABILITIES USING THE
	    BLOCK COMMAND.  THIS FORM OF OPEN WILL THEREFORE BE ILLEGAL
	    ON ALL DEVICES WHICH CANNOT SUSTAIN BOTH THESE CAPABILITIES

	2-  CREATE A NEW LINKED FILE (OPENO)

	    THIS FORM OF OPEN WILL NORMALLY PRECEDE ALL WRITE OPERA-
	    TIONS ON ANY DEVICE AND WILL ESTABLISH A DATA-BUFFER WHICH
	    WILL BE CLEARED IN PREPARATION FOR THE SUBSEQUENT TRANSFERS.
	    ON NON-FILE ORIENTED DEVICES IT MAY ALOS CAUSE THE OUTPUT
	    OF SOME INITIALIZING DATA AT THE DEVICE SUCH AS LEADER CODE
	    FROM A PUNCH A FORM-FEED FROM A PRINTER.

	3-  EXTEND AN EXISTING LINKED FILE (OPENE)

	    ALTHOUGH PRIMARILY INTENDED FOR FILE-ORIENTED DEVICE USAGE
	    THIS TYPE OF OPEN WILL OPERATE AS OPENO ON ALL THESE DEVICES.

	4-  OPEN AN EXISTING FILE FOR INPUT (OPENI)

	    THIS TYPE OF OPEN WILL NORMALLY BE USED BEFORE ALL READ
	    OPERATIONS.  FOR NON-FILE ORIENTED DEVICES IT MAY CAUSE
	    A CALL TO THE DEVICE DRIVER FOR A CHECK AS TO THE DEVICE
	    READINESS TO PROVIDE DATA.  ON ALL DEVICES A DATA-
	    BUFFER WILL BE ESTABLISHED AND FILLED IN ANTICIPATION OF
	    THE FIRST READ.

	5-  OPEN AN EXISTING CONTIGUOUS FILE FOR OUTPUT (OPENC)

	    OPENC IS MAINLY PROVIDED AS THE MEANS WHEREBY A USER MAY
	    ACCESS A CONTIGUOUSLY ALLOCATED AREA ON A BULK-STORAGE
	    DEVICE FOR SEQUENTIAL WRITE OPERATIONS.  FOR NON-FILE
	    DEVICES IT WILL BE TREATED AS OPENO.

	FILE-NAME, EXTENSION, UIC AND PROTECTION

	THESE ENTRIES ARE REQUIRED ONLY FOR FILE-ORIENTED DEVICE
	USAGE AND ARE DESCRIBED UNDER "FILE STRUCTURES".  FOR FULL
	DEVICE-INDEPENDENCE, THE USER MUST ALLOW THE REQUISITE-
	FIVE WORD SPACE EVEN THOUGH IT NEED CONTAIN NO SPECIFIC
	ENTRIES.

	THE FOLLOWING MATRIX ILLUSTRATES THE METHODS OF ACCESS PER-
	MITTED FOR EACH OF THE WAYS A USER MAY OPEN A FILE.

		SEQUEN-	SEQUEN-	RANDOM	RANDOM	TYPE OF FILE
		TIAL	TIAL	READ	WRITE
		READ	WRITE
	----------------------------------------------------------------
	OPENO		 YES			LINKED
	----------------------------------------------------------------
	OPENI	 YES		 YES		LINKED OR CONTIGUOUS
	----------------------------------------------------------------
	OPENE		 YES			LINKED
	----------------------------------------------------------------
	OPENU		 YES	 YES		LINKED OR CONTIGUOUS
	----------------------------------------------------------------
	OPENC		 YES		 YES	CONTIGUOUS
	----------------------------------------------------------------

	THERE ARE NO RESTRICTIONS, OTHER THAN THE LIMITS OF CORE,
	ON THE NUMBER OF FILES A USER MAY HAVE OPEN AT ANY TIME.  THE
	RESTRICTIONS IMPOSED BY THE MONITOR REFER ONLY TO HOW THE USER
	MAY ACCESS THE DATA OF THE FILE.

	THE CLOSE CALL WILL BE THE MEANS WHEREBY OPERATIONS ON A DATASET
	ARE TO BE TERMINATED.  CLOSE PROCESSING WILL INCLUDE THE OUTPUT
	OF ANY DATA NOT YET PASSED TO A DEVICE, ANY NECESSARY SHUT-DOWN
	ACTION BY A NON-FILE STRUCTURED DEVICE (E.G. PUNCHING OF TRAILER
	CODE ON A PAPER TAPE PUNCH), DIRECTORY HOUSEKEEPING ON A FILE
	ORIENTED DEVICE, AND FINALLY, THE RELEASE OF THE DATA BUFFER 
	USED FOR TRANSFERS.  THE DEVICE DRIVER AND THE DDB WILL REMAIN
	IN CORE AND REMAIN LINKED TO THE USER PROGRAM.  OPERATIONS MAY
	THUS BE RESUMED BY THE ISSUE OF ANOTHER OPEN CALL.


6.4.3	DEVICE INDEPENDENCE

	IN SECTION 6.4.2., IT HAS BEEN ASSUMED THAT THE USER WILL
	WISH TO SPECIFY ALL THE DEVICES HE WILL USE AT THE TIME OF
	WRITING THE PROGRAM.  THIS ASSUMPTION IS PROBABLY CORRECT
	FOR MANY APPLICATIONS PROGRAMS BUT IT CERTAINLY DOES NOT
	HOLD FOR MANY OTHER PROGRAMS.  EVEN IN THE FORMER CASE
	THERE WILL BE OCCASIONS WHEN THE USER WILL WANT TO CHANGE
	HIS SPECIFICATION FOR PRACTICAL REASONS SUCH AS THE TEMPO-
	RARY NON-AVAILABILITY OF THE NAMED DEVICE OR ITS UNSUITABILITY
	IN PARTICULAR TIME-CRITICAL SITUATIONS.  THE FOLLOWING FURTHER
	FACILITIES WILL THEREFORE BE PROVIDED:

	A)  BEFORE LOADING A PROGRAM THE USER WILL HAVE THE
	    FACILITY OF EQUATING A DIFFERENT DEVICE AND FILE TO THE
	    LOGICAL DATA-SET NAME THROUGH AN ASSIGN COMMAND AT THE
	    CONSOLE TYPEWRITER.  SUCH ASSIGNMENT WILL BE STORED IN A
	    MONITOR TABLE.

	B)  BOTH THE INIT & OPEN PROCESSING ROUTINES WILL HONOR
	    ENTRIES IN THE ASSIGNMENT TABLE DURING THE OPERATIONS
	    DESCRIBED IN 6.4.2.  IN DEFAULT, THE PROGRAM 
	    SPECIFICATION WILL STAND.

	C)  FOR PROGRAMS WHERE NO DEVICE ASSIGNMENT IS POSSIBLE (SUCH
	    AS SYSTEMS PROGRAMS), A MONITOR COMMAND DECODER
	    ROUTINE WILL BE AVAILABLE.  (SEE SECTION 11.3.11)
	    THIS ROUTINE WILL BE RESPONSIBLE FOR ASKING THE USER
	    IN A PARTICULAR PASS OF THE SYSTEM PROGRAM AND WILL
	    SET UP THE CORRESPONDING LINKAGES.  THE SYSTEM
	    PROGRAM WILL THEN EFFECT ITS OWN TRANSFERRING AND
	    CLOSING AS REQUIRED.


6.4.4	DEVICE DRIVER

	A DEVICE DRIVER WILL NORMALLY BE CALLED ONLY TO
	TRANSFER A BLOCK OF DATA.  THE MONITOR ROUTINE WILL
	SET UP THE NECESSARY CONTROLS IN THE DDB AND PASS
	THE ADDRESS OF THIS BLOCK TO THE DRIVER AS A CALLING
	ARGUMENT.  THE ROUTINE WILL ALSO SUPPLY THE ADDRESS TO
	WHICH THE DRIVER SHOULD RETURN AFTER GETTING THE
	TRANSFER UNDERWAY.

	THE DRIVER MAY ALSO NEED TO SUPPLY SPECIAL FACILITIES
	PARTICULARLY IF THE DEVICE PERFORMS OUTPUT, SUCH AS
	PUNCHING LEADERS OR TRAILERS ON PAPER TAPE OR SKIPPING
	TO A NEW FORM BEFORE AND AFTER LINE PRINTER LISTINGS, OR
	IF THE DEVICE IS BULK STORAGE, SUCH AS REWINDING OR SKIPPING
	RECORDS.

	SEE SECTION 11.5 FOR A DETAILED DESCRIPTION OF THE
	DEVICE DRIVER FORMAT.

6.4.5	BUFFERING SCHEME

	THE DYNAMIC BUFFER MANAGEMENT SCHEME IS DESCRIBED IN
	SECTION 11.3.3.  IT WILL BE USED NOT ONLY FOR THE PRO-
	VISION OF DATA BUFFERS BUT ALSO FOR THE ESTABLISHMENT
	OF DDB'S AND FIB'S AND THE LOADING OF NON-RESIDENT
	DRIVERS.  ALTHOUGH THE CORE OCCUPIED BY THESE OTHER
	ITEMS WILL BE RELEASED LESS FREQUENTLY THAN THAT ASSIGNED 
	TO DATA BUFFERS, IT IS LIKELY TO BE LOWER IN THE FREE
	AREA AVAILABLE AND HENCE IT WILL NOT CREATE POCKETS
	WHICH CANNOT BE DEALLOCATED ALTHOUGH NO LONGER REQUIRED.


6.4.6	USER INTERFACE

	ALTHOUGH MOST USERS WILL BE EXPECTED TO CARRY OUT THEIR
	I/O OPERATIONS THROUGH THE MONITOR'S USER-LINE AND DEVICE-
	BLOCK TRANSMISSION SCHEME SO FAR DISCUSSED THERE WILL BE
	OCCASIONS WHEN A MORE DIRECT LINKAGE TO THE DEVICE HANDLER
	IS REQUIRED.

	HOWEVER, IT WILL STILL BE ADVISABLE FOR THE MONITOR
	TO RETAIN SOME MEASURE OF CONTROL PARTICULARLY IF THE
	DEVICE IS LIKELY TO BE ALREADY BUSY BECASUE IT IS
	SERVICING SEVERAL DATA SETS OR IF BUFFER AVAILABILITY IS
	IN DOUBT.  THE BLOCK AND TRANS FUNCTIONS WILL BE PROVIDED
	FOR THIS DIRECT ACCESS TO DEVICE HANDLERS.  SEE THE
	DESCRIPTION OF BLOCK AND TRANS BELOW. 

6.4.7	INTERRUPT SERVICING AND PRIORITY

	IN GENERAL, INTERRUPT SERVICING FOR ANY DEVICE WILL BE
	PERFORMED AT THE PRIORITY LEVEL OF THE DEVICE.  USER
	REQUESTS WILL BE PERFORMED AT THE USER LEVEL (LEVEL 0).
	OR AT THE LEVEL OF THE CALL FOR REAL TIME APPLICATIONS.
	IT IS RECOGNIZED THAT SOME OPERATIONS (E.G. COMMON TABLE
	MANIPULATION) WILL REQUIRE INHIBITING INTERRUPTS FOR
	SHORT PERIODS OF TIME.


6.5	DISCUSSION OF "SLOT" TYPE SCHEME

	AN ALTERNATIVE METHOD OF DATA-SET IDENTIFICATION TO THAT
	DESCRIBED WOULD BE ONE IN WHICH THE USER WOULD ASSOCIATE
	EACH SET WITH A NUMBERED SOFTWARE CHANNEL OR "SLOT".
	THE SLOT METHOD HAS THE POTENTIAL ADVANTAGE THAT IT
	WOULD NOT USE STORAGE WITHIN THE CALLING PROGRAM
	FOR LOGICAL NAME OR DEFAULT DEVICE NAME, THE FORMER BEING
	UNNECESSARY AND THE LATTER BEING STORED WITHIN THE
	MONITOR SLOT ITSELF.

	HOWEVER, THE SLOT-NUMBER SCHEME HAS THE FOLLOWING MAJOR
	DISADVANTAGES:

	A)  THE NUMBER MUST STILL BE CONVERTED TO AN ADDRESS
	    BEFORE USE THEREBY CREATING A MONITOR OVERHEAD AT 
	    EVERY I/O CALL, WHEREAS THE ADDRESS IS IMMEDIATELY
	    AVAILABLE IN THE PROPOSED SCHEME.

	B)  THE USE OF NUMBERS, IF THEY ARE TO HAVE ANY VALUE
	    IN A MULTI-SEGMENTED PROGRAM, PRESUPPOSES A FIXED
	    SEQUENTIAL TABLE BEING HELD AT ALL TIMES WITHIN THE
	    MONITOR REGARDLESS OF WHETHER THE USER REQUIRES ALL
	    OR ONLY SOME OF THEM.

	C)  BECAUSE SUCH A TABLE IS A PART OF THE MONITOR, ANY
	    CHANGES IN EITHER ITS LENGTH OR ITS CONTENT TO MEET
	    THE REQUIREMENTS OF A PARTICULAR PROGRAM NORMALLY
	    NECESSITATE REBUILDING THE ENTIRE MONITOR, ADDING
	    AN UNNECESSARY FRUSTRATION.

	THE PROPOSED SCHEME WAS CHOSEN FOR EVEN THOUGH A FEW
	EXTRA BYTES MAY BE TAKEN PER DATA-SET TO PUT THE
	IDENTIFICATION DETAIL WITHIN THE USER PROGRAM, THIS
	DETAIL WILL AUTOMATICALLY EXPAND, CONTRACT OR VARY WITH THE
	NEEDS OF EACH PROGRAM RATHER THAN THOSE OF THE INSTALLATION
	AND THE USER IS THEREBY GIVEN GREATER FLEXIBILITY.




6.6	THE READ/WRITE PROCESSOR

	BY MEANS OF A READ CALL, THE USER MAY REQUEST A LINE OF DATA AS
	ASCII CHARACTERS OR BINARY WORDS, WITH OR WITHOUT FORMATTING.
	IN ORDER THAT THE SIZE OF THE LINE MAY BE ENTIRELY INDEPENDENT
	OF THE TYPE OF DEVICE BEING USED, THE READ-WRITE PROCESSOR
	WILL MAINTAIN, AS FAR AS POSSIBLE IN ADVANCE OF THE PROGRAM'S 
	REQUIREMENTS, A SUPPLY OF DATA IN A BUFFER ALLOCATED AS RE-
	QUIRED FROM AVAILABLE FREE CORE AND OF A SIZE DEEMED STANDARD
	FOR THE DEVICE CONCERNED.  SIMILARLY A WRITE CALL WILL ENABLE
	THE TRANSFER OF LINES OF DATA WHICH WILL BE BUFFERED AND THEN
	TRANSMITTED TO THE DEVICE IN STANDARD BLOCKS.

	THE READ-WRITE PROCESSOR ITSELF MAY AT THE USER'S DISCRETION
	BE RESIDENT TRROUGHOUT THE PROGRAM RUN OR BE BROUGHT INTO CORE
	ONLY WHEN NEEDED.  WHILE IN CORE, IT WILL BE FREELY SHARABLE
	BY ALL OUTSTANDING READ OR WIRTE CALLS.

	USER LINE BUFFER:

	THE USER PROGRAM MUST PROVIDE A BUFFER FOR THE LINE TRANSFER
	IMMEDIATELY PRECEDED BY THREE WORDS OF HEADER INFORMATION IN
	THE FOLLOWING FORMAT:

	WORD 1:	LINE SIZE -  THIS WILL BE THE TOTAL NUMBER OF DATA
		BYTES THE BUFFER MAY CONTAIN.  THE USER MUST SUPPLY
		THIS INFORMATION FOR INPUT AS IT WILL PROVIDE THE
		ULTIMATE CONTROL ON THE BYTES TRANSFERRED, REGARDLESS
		OF THE DATA MODE.  ON OUTPUT, IT WILL BE IGNORED BUT
		MAY BE USED BY THE PROGRAM FOR ITS OWN CONTROLS.

	WORD2:
	BYTE 0:	MODE -  BY THIS, THE USER WILL SHOW THE TYPE OF PROCESS-
		ING THE DATA SHOULD RECEIVE.  BASICALLY, BITS WILL BE
		ALLOCATED TO SPECIFIC FEATURES AS FOLLOWS:


		BITS 7-4	BIT3	BIT 2	BIT 1		BIT 0
				NO
	BIT=0	CURRENTLY NOT	PARITY	NORMAL	FORMATTED	ASCII

	BIT=1	USED		PARITY	DUMP	UNFORMATTED	BINARY



	THE MODES PRESENTLY ESTABLISHED ARE:
	CODE 0	FORMATTED ASCII -  IN THIS MODE, A LINE IS EXPECTED TO 
		TERMINATE WITH A LINE-CONTROL CHARACTER (LINE-FEED,
		VERT. TAB OR FORM-FEED).  FOR BOTH INPUT AND OUTPUT THE
		TRANSFER WILL STOP WHEN SUCH DELIMITER IS SEEN,
		REGARDLESS OF THE STIPULATED BYTE COUNT; IF, HOWEVER, THE
		COUNT RUNS OUT BEFORE A DELIMITER IS SEEN, THE TRANSFER
		WILL END AND A SHORT LINE ERROR RETURNED TO THE USER
		(SEE STATUS BYTE BELOW).

		DURING INPUT, ALL CHARACTERS WILL BE PASSED TO THE USER
		AS SEVEN-BIT VALUES AND NULLS AND RUBOUTS WILL BE
		DISCARDED.  FOR OUTPUT, SEVEN-BIT CHARACTERS WILL BE
		TRANSFERRED.  HORIZONTAL TABULATION WILL BE FOLLOWED
		BY RUBOUT; VERTICAL TABULATION AND FORMFEED BY
		APPROXIMATELY 2" OF BLANK TAPE.


	CODE 1	FORMATTED BINARY - THE OUTPUT OF A BINARY LINE WILL
		COMMENCE AT THE HEADER WORD.  A CHECKSUM OF ALL BYTES
		TRANSFERRED (INCLUDING THE TWO HEADERS) WILL BE ACCUM-
		ULATED AND THE TW0'S COMPLEMENT OF THE JUNIOR BYTE OF
		THIS SUM WILL BE OUTPUT FOLLOWING THE LAST DATA BYTE.
		THE NUMBER OF DATA BYTES WILL BE CONTROLLED BY THE COUNT
		GIVEN IN WORD 3, ADJUSTED BY 4 TO COVER THE HEADER
		WORDS.  UP TO 7 NULL BYTES WILL FOLLOW THE CHECKSUM
		AS AN INTERLINE GAP.

		INPUT WILL IGNORE ALL BYTES OF WHATEVER VALUE, UNTIL A
		1 IS SEEN (I.E. A REPLICA OF THIS BYTE) TRANSFER WILL
		BEGIN AT THIS POINT AND TERMINATE WHEN THE BYTE COUNT
		READ IN FROM THE DEVICE RUNS OUT.  CHECKSUMMING OF EACH
		BYTE READ WILL BE EFFECTED AND THE RESULT COMPARED WITH
		THAT AT THE END OF THE DATA.  AN ERROR WILL BE SIGNALLED
		IN THE STATUS BYTE.  IF THE LINE BUFFER SIZE IS EXCEEDED
		BEFORE THE END OF THE LINE IS REACHED, THE TRANSFER
		WILL STOP AND A SHORT LINE WILL BE SIGNALLED.

	CODE 2	UNFORMATTED ASCII - SEE CODE 3

	CODE 3	UNFORMATTED BINARY -  BOTH THESE MODES ARE
		PROVIDED FOR THE BENEFIT OF THE USER
		WHO WISHES TO UNDERTAKE HIS OWN CHECKING AND VERIFICATION
		ENTIRELY.  AS A RESULT, THE READ-WRITE PROCESSOR WILL
		MERELY TRANSFER BYTES UNTIL THE SPECIFIED BYTE COUNT
		RUNS OUT.

	CODE 4	DUMP ASCII - SEE CODE 5

	CODE 5	DUMP BINARY - THESE MODES WILL ENABLE THE USER
		TO TRANSFER TO OR FROM SECTIONS OF ESTABLISHED
		CORE FOR WHICH IMMEDIATE PRECEDENCE BY HEADER INFORMATION
		WOULD BE IMPRACTICABLE.  THE HEADERS WILL THEREFORE BE
		DEEMED TO FORM A SEPARATE BLOCK FOLLOWED BY A FOURTH
		WORD WHICH SHOULD POINT TO THE START OF THE TRANSFER
		AREA.  OTHERWISE, THE DUMP MODES WILL BE PROCESSED
		EXACTLY AS THE UNFORMATTED MODES DESCRIBED ABOVE.

	CODE 6/7 INVALID -   WILL BE HANDLED AS DUMP MODES 4/5

	CODE 10	PARITY ASCII - IN THE INTEREST OF CORE ECONOMY PARITY
		CHECKING OR GENERATION WILL BE POSSIBLE ONLY AT A COST
		APPROXIMATELY 40-50 USECS A CHARACTER.  THIS MODE IS
		THEREFORE PROVIDED SEPARATELY FOR THE USER WHO MUST
		CONSIDER PARITY AND IS PREPARED TO SUFFER THIS COST.
		DURING OUTPUT, A SENIOR EIGHTH BIT WILL BE ADDED
		TO THE NORMAL 7-BIT ASCII TO PRODUCE EVEN PARITY.
		ON INPUT, EVEN PARITY WILL BE CHECKED AND IF CORRECT, 7
		BITS WILL BE PASSED TO THE USER.  A PARITY ERROR WILL
		BE SIGNALLED IN THE STATUS BYTE (SEE BELOW) AND BIT 8
		OF THE ILLEGAL CHARACTER WILL BE SET.  IN ALL OTHER
		RESPECTS, THIS MODE WILL EQUATE TO FORMATTED ASCII.


	ALL OTHER CODES (11-377) WILL BE CONSIDERED ILLEGAL AND WILL BE
	SIGNALLED AS SUCH.

	BYTE 1:	STATUS  THIS BYTE WILL BE USED BY THE READ-WRITE
	PROCESSOR TO RETURN INFORMATION TO THE USER PROGRAM WHEN A 
	TRANSFER HAS BEEN COMPLETED.  ITS FORMAT IS DESCRIBED UNDER "ERROR
	CONDITIONS" BELOW.  THE PROCESSOR WILL CLEAR IT BEFORE THE TRANS-
	FER IS CARRIED OUT.

	WORD 3	BYTE COUNT  THIS COUNT WILL PROVIDE THE ULTIMATE CONTROL
		ON THE NUMBER OF BYTES OUTPUT ON WRITE AND MUST THEREFORE
		BE FURNISHED BY THE USER PROGRAM.  (FOR FORMATTED ASCII
		MODES, IT NEED NOT BE ACCURATE AS LONG AS IT IS GREATER
		THAN OR EQUAL TO THE NUMBER OF CHARACTERS UP TO AND INCLUDING
		 THE LINE DELIMITER.)  BEFORE A READ, IT WILL BE IRRELEVANT
		AFTER BOTH INPUT AND OUTPUT, THE PROCESSOR WILL RETURN
		(IN THIS WORD) A COUNT OF THE BYTES ACTUALLY TRANSFERRED.


6.7	TRAN PROCESSOR

	THE TRAN MONITOR CALL WILL ENABLE THE USER TO PERFORM DIRECT
	TRANSFERS BETWEEN A DEVICE AND A MEMORY AREA WITHOUT INTERMEDIATE
	MONITOR BUFFERING AND WITH THE SIZE OF THE TRANSFER LIMITED ONLY
	BY THE CAPACITY OF A WORD AS A COUNTER (65K).  THE MONITOR WILL,
	HOWEVER, EXERCISE ITS NORMAL CONTROL OVER THE USE OF THE DEVICE -
	I.E. ALLOWING THE TRANSFER ONLY IF THE DEVICE IS CURRENTLY IDLE
	AND QUEUEING THE REQUEST OTHERWISE.

	IN ORDER TO PROVIDE THE PARAMETERS BY WHICH THE TRANSFER WILL
	BE CONTROLLED, THE USER MUST ESTABLISH A TRANSFER BLOCK OF THE
	FOLLOWING FORMAT WITHIN HIS PROGRAM:

	      TRANSBLK:	DEVICE BLOCK NO.

			MEMORY START ADDR.

			NUMBER OF WORDS TO TRANSFER

			FUNCTION
		
			NUMBER OF WORDS
			NOT TRANSFERRED


	THE BITS OF THE FUNCTION WORD ARE AS FOLLOWS:

		0 - NOT USED
		1 - WRITE
		2 - READ
	     3-10 - NOT USED
	       11 - DEC TAPE DIRECTION (0=FORWARD)
	    12-13 - UNUSED
	       14 - END OF DATA
	       15 - DEVICE PARITY

	THE .TRAN PROCESSOR WILL INDICATE ERROR INFORMATION BACK TO THE 
	USER AS 1 IN BIT 15 OF THE FUNCTION WORD OF THE CONTROL
	BLOCK AND THE NUMBER OF WORDS NOT TRANSFERRED AS A POSITIVE
	VALUE IN THE LAST WORD OF THE USER'S CONTROL BLOCK.



7.0	LANGUAGE

	NOT APPLICABLE

8.0	COMMAND LANGUAGE

8.1	OPERATOR/MONITOR INTERACTION

	THE PDP-11 DISK MONITOR PROVIDES A COMPLETE SET OF COMMANDS
	FOR OPERATOR CONTROL OF THE SYSTEM.  THESE COMMANDS ARE
	DESIGNED TO ACCOMMODATE BOTH REAL TIME AND NON-REAL TIME
	PROCESSING APPLICATIONS.

8.2.1	SYNTAX

	THE COMMANDS ARE EACH EXPLAINED IN DETAIL BELOW.  THE
	SYNTAX USED TO FACILITATE CONCISE STATEMENT OF ALL VARIATIONS
	OF EACH COMMAND IS AS FOLLOWS:

	BRACKETS, [ ], WILL BE USED TO ENCLOSE ELEMENTS
	OF THE COMMAND WHICH ARE OPTIONAL, I.E. THEY MAY
	APPEAR OR NOT APPEAR DEPENDING ON THE DESIRED
	MONITOR REACTION.

	BRACES,    , ARE USED TO INDICATE THAT A CHOICE
	MUST BE MADE FROM THE ENCLOSED INFORMATION.

	ALL WORDS (OR LETTERS) ARE KEYWORDS AND MUST
	APPEAR AS STATED.

	THE APPEARANCE OF A, INDICATES THAT EITHER A COMMA
	AND/OR SPACES MUST APPEAR IN THAT POSITION.

	ALL KEYBOARD COMMANDS WILL BE TERMINATED WITH A CARRIAGE 
	RETURN.

8.2.2	STANDARD NOMENCLATURE

	IN THE COMMAND SYNTAX BELOW, THE FOLLOWING NAMES
	WILL BE USED TO REPRESENT THE INFORMATION AS
	GIVEN:

	DEVICE NAME

	DEVICE NAME REPRESENTS A PHYSICAL I/O DEVICE.
	ONE OF THE FOLLOWING MAY BE SUPPLIED (DEPENDING
	UPON CONFIGURATION):

		DF - RF11 DISK
		DK - RK11 DISK
		DT - DECTAPE (DT11)
		KB - TELETYPE KEYBOARD USED AS A CON-
		     VERSATIONAL DEVICE
		LP - LINE PRINTER (LP11)
		MT - MAGNETIC TAPE
		PP - HIGH SPEED PAPER TAPE PUNCH
		PR - HIGH SPEED PAPER TAPE READER
		TT - TELETYPE USED AS A NORMAL DEVICE

	FOR MULTI-CONTROLLER DEVICES, A NUMBER IMMEDIATELY FOLLOWING
	THE DEVICE CODE SERVES TO IDENTIFY THE DESIRED CONTROLLER,
	E.G. DT5 WOULD REFER TO DECTAPE CONTROLLER 5.

	FILE NAME

	WHERE EVER "FILE NAME" APPEARS IN THE SYNTAX BELOW
	ANY PORTION OF THE FOLLOWING (NON-SYNTACTICAL)
	EXPRESSION MAY BE SUPPLIED:

		FILENM.EXT[UIC]<PROTECT>

	WHERE FILENM REPRESENTS A 6 CHARACTER FILENAME,
	EXT IS A 3 CHARACTER EXTENSION (PRECEEDED BY "."
	WHEN PRESENT, UIC IS THE USER IDENTIFICATION CODE 
	(SEE SECTION 5) IF DIFFERENT FROM THE CURRENT USER,
	AND PROTECT IS THE DESIRED PROTECTION CODE FOR 
	CREATED FILES (SEE SECTION 5).

	LOGICAL NAME

	LOGICAL NAME IS THE NAME GIVEN TO THE DATASET BY 
	THE USER.


8.3	KEYBOARD COMMAND LANGUAGE:

	AS[SIGN] DEVICE NAME:[FILENAME], LOGICAL NAME

	ASSIGNS LOGICAL (DATA SET) NAME, WHICH IS INTERNAL
	TO USER PROGRAM, TO THE ACTUAL PHYSICAL DEVICE (OR
	DATA) SPECIFIED.

	BE[GIN] [,ADDRESS]

	ADDRESS SPECIFIES OCTAL ADDRESS AT WHICH TO BEGIN EXECUTION.
	BEGIN IS USED AFTER GET OR WAIT.  IF NO ADDRESS IS
	SPECIFIED, ADDRESS USED WILL BE NORMAL START ADDRESS.

	CO[NTINUE]

	USED AFTER WAIT TO RESUME OPERATION AT THE INSTRUCTION
	FOLLOWING THE INTERRUPT POINT.

	DA[TE] [,DAY]

	ENTER DAY (IN JULIAN-70,000) IF SPECIFIED, OTHERWISE TYPE
	OUT DATE.

			      I         START ADDRESS
	DU[MP],DEVICE NAME,   O ,  ,    0              ,END ADDRESS 

	WRITE SPECIFIED CORE AREA (OR ALL OF CORE) ON OR FROM
	SPECIFIED DEVICE.  I SPECIFIES DUMP TO CORE, O IS DUMP
	FROM CORE.  O IS ASSUMED.

	EX[ECUTE] (RESERVED FOR CCL)

		   DEVICE:[FILENAME]
	GE[T] ,    FILENAME            

	LOAD (ONLY) PROGRAM FROM DISK OR SPECIFIED BINARY 
	INPUT DEVICE.

	FI[NISH]

	INFORM THE MONITOR THAT THE CURRENT USER IS
	LEAVING THE SYSTEM.  NO USER PROGRAM MAY BE
	RUNNING WHEN THE FINISH COMMAND APPEARS.

	KI[LL]

	KILL CURRENT PROGRAM AFTER ALLOWING SAFE CLOSING
	OF ALL OPEN FILES AND COMPLETION OF OUTSTANDING I/O.

	LO[GIN], USER IDENTIFICATION CODE

	THIS COMMAND IS USED TO GIVE THE MONITOR THE USER'S
	USER IDENTIFICATION CODE (UIC).  THE UIC IS USED
	BY THE FILE SYSTEM TO DIFFERENTIATE BETWEEN SEVERAL
	SYSTEM USERS.

	MO[DIFY] OCTAL ADDRESS		[CHANGE]

	ALLOW ABSOLUTE PATCHES.  THE OPTIONAL CHANGE IS SPECIFIED
	AFTER MONITOR PRINTS THE CONTENTS OF THE SPECIFIED ADDRESS.

	OT[HER] DEVICE NAME [:FILENAME]

	THE STATED DEVICE IS MADE THE MONITOR COMMAND DEVICE.  THE
	KEYBOARD MAY BECOME THE COMMAND DEVICE BY ^C FROM THE KEY-
	BOARD OR THE APPEARANCE OF AN "OTHER KB" COMMAND ON THE OTHER
	DEVICE.

	RE[START] [ADDRESS]

	RESTART THE CURRENTLY RESIDENT PROGRAM AT ITS STATED  RESTART
	ADDRESS (IN THE SYSTEM VECTOR TABLE) OR AT THE ADDRESS STATED.

	RU[N]	DEVICE:	[FILE NAME]
		FILENAME

	LOAD AND EXECUTE (TRANSFER TO INDICATED ENTRY POINT) SPEC-
	IFIED PROGRAM FROM DISK OR SPECIFIED BINARY INPUT DEVICE.

	ST[OP]

	IMMEDIATELY SUSPEND ALL PROGRAM ACTIVITY INCLUDING ANY
	I/O IN PROGRESS.  PROGRAM ACTIVITY MAY BE RESUMED THROUGH
	USE OF THE CONTINUE OR RESTART COMMAND.

	SY[STEM]

	ALLOWS THE OPERATOR TO INQUIRE ABOUT VARIOUS SYSTEM STATUSES.

	TI[ME] [,TIME]

	SET THE TIME OF DAY TO THE TIME IF TIME IS SPECIFIED,
	OTHERWISE TYPE THE TIME OF DAY.

	WA[IT]

	SUSPEND CURRENT PROGRAM UNTIL OPERATOR GIVES A BEGIN OR CONTINUE
	THE PROGRAM WILL BE RETURNED TO ITS PREVIOUS STATUS BY THE
	CONTINUE COMMAND.

	SPECIAL CHARACTERS

	ALTMODE

	THE ALTMODE CHARACTER CAUSES SUPPRESSION OF MONITOR
	 ACTION ON THE ONE FOLLOWING CHARACTER (ALLOWING ^C AS
	INPUT TEXT).  ALTMODE WILL BE ECHOED AS "CLICK"

	^C

	THE CONTROL C IS USED TO ALERT MONITOR THAT A MONITOR
	MESSAGE WILL FOLLOW.  ECHOED AS ^C
	
	^U

	THE CONTROL U CAUSES THE CURRENT PARTIAL LINE [INPUT OR
	OUTPUT) TO BE FLUSHED FROM THE SYSTEM.  ECHOED AS ^U
	<CR,LF>.

	ALL CONTROL CHARACTERS WILL BE ECHOED AS ^ CHARACTER.

	;

	THE ; CAUSES ALL CHARACTERS UP TO THE FOLLOWING CR TO BE 
	TREATED AS COMMENTS.  CHARACTERS PRECEEDING THE ; WILL BE
	TREATED AS NORMAL.  IF THE ; BEGINS A LINE, I.E. NO ^C HAS
	APPEARED, THE MONITOR BEGINS ECHOING WITH THE ;.

8.4	EXECUTING PROGRAM/MONITOR COMMUNICATION
	
	DURING ITS EXECUTION A USER PROGRAM MAY COMMUNICATE WITH THE
	MONITOR THROUGH USE OF THE EMULATE TRAP (EMT) INSTRUCTION.
	THE USER IDENTIFIES HIS REQUEST THROUGH USE OF THE CODE IN
	THE LOW ORDER BYTE OF THE EMT INSTRUCTION.  CODES AND THE
	REQUESTS THEY REPRESENT ARE GIVEN IN NUMERICAL ORDER
	BELOW.  THE CALLING SEQUENCE FOR EACH REQUEST IS ALSO
	GIVEN.  THE READER IS REFERRED TO SECTIONS 6 AND 5 FOR BLOCK
	FORMATS AND FILE STRUCTURE FORMATS RESPECTIVELY.

8.4.1	WAITR

	CALLING SEQUENCE

		MOV	BUSY ADDRESS,-(SP)
		MOV	#LINK BLOCK,-(SP)
		EMT	0

	MONITOR RESPONSE

	IF THE DATASET REPRESENTED BY THE REFERENCED LINK BLOCK IS
	CURRENTLY BUSY THE BUSY ADDRESS WHICH WAS PLACED ON THE STACK
	IS TAKEN.  IF THE DATASET IS NOT BUSY THE NEXT SEQUENTIAL 
	INSTRUCTION IS THE RETURN POINT.  THE DATASET IS BUSY ONLY IF
	THE LAST REQUESTED ACTION ON THE DATASET IS NOT COMPLETE
	(WHETHER DEVICE ACTIVITY IS CURRENTLY IN PROGRESS OR NOT)

8.4.2	WAIT

	CALLING SEQUENCE

		MOV	#LINK BLOCK,-(SP)
		EMT	1

	MONITOR RESPONSE

	WHEN THE DATASET REPRESENTED BY THE LINKBLOCK IS NOT BUSY, THE
	MONITOR RETURNS TO THE USER AT THE NEXT SEQUENTIAL INSTRUCTION.
	THE MONITOR RETAINS CONTROL UNTIL THE DATASET NOT BUSY.

8.4.3	READ/WRITE PROCESSOR

	EMT CODES 2,3,4, AND 5 ALL REFER TO THE READ/WRITE INPUT/
	OUTPUT PROCESSOR.

	CALL SEQUENCES:

	TO REQUEST READ OR WRITE THE USER PROGRAM WILL CALL THE 
	PROCESSOR BY THE FOLLOWING SEQUENCE:

		MOV	#LINE,-(SP)
		MOV	#LINK BLOCK,-(SP)
		EMT	X

	WHERE "LINE" IS THE SYMBOLIC ADDRESS OF THE FIRST HEADER
	WORD OF THE USER LINE AS DESCRIBED IN SECTION 6.6, LINK
	BLOCK IS THE PROGRAM'S LINK-BLOCK THE RELEVANT DATA-SET
	AND X WILL BE 2 FOR WRITE OR 4 FOR READ.  (WHEN THE CURRENT 
	MONITOR IS EXPANDED TO PROVIDE REAL-TIME OPERATIONS REALW 
	WILL USE 3 AND REALR 5).  THE CALL-SEQUENCE (ESPECIALLY WHEN
	OBTAINED VIA A SYTEM MACRO) MAY ALSO CONTAIN A PARAMETER BY
	WHICH THE USER WILL INDICATE HIS REQUIREMENTS FOR READ-WRITE
	PROCESSOR CORE-RESIDENCY.

	GENERAL PROCESSING.

	THE READ-WRITE PROCESSOR WILL INITIALLY CHECK THAT THE REQUESTED
	TRANSFER IS POSSIBLE.  FIRSTLY THE MODE SPECIFIED MUST BE LEGAL
	AND BE WITHIN THE CAPABILITY OF THE ASSOCIATED DEVICE (E.G. 
	A LINE-PRINTER CAN HANDLE ASCII DATA ONLY).  SECONDLY, IF 
	THE DEVICE IS FILE-STRUCTURED, READ OR WRITE REQUIRE THAT THE
	NECESSARY FILE BE MADE AVAILABLE BY A PRIOR OPEN CALL, WHICH
	MUST ITSELF BE A VALID ONE (I.E. WRITE CAN FOLLOW OPENO OR OPENE,
	OR READ AN OPENI).

	THE ACTUAL TRANSFER OF DATA TO OR FROM THE USER LINE WILL BE
	BY WAY OF A BUFFER CLAIMED FOR THE PURPOSE FROM FREE CORE
	AND OF SIZE DEEMED STANDARD FOR THE DEVICE CONCERNED.  IF
	THE USER HAS PREVIOUSLY MADE AN OPEN CALL, THIS BUFFER WILL
	HAVE ALREADY BEEN SET-UP AND FILLED WITH DATA (FOR INPUT) OR
	CLEARED (FOR OUTPUT).  IF NOT THE READ-WRITE PROCESSOR WILL
	EFFECT SUCH ACTION PROVIDED OF COURSE FREE CORE STILL EXISTS.

	WHILE SUFFICIENT DATA (OR ROOM FOR IT) EXISTS WITHIN THE 
	BUFFER, THE READ-WRITE PROCESSOR WILL MEET THE USER'S READ
	OR WRITE CALL IMMEDIATELY AND RETURN TO THE USER PROGRAM 
	WITH THE DATA SET-FLAG CLEARED.  IF, HOWEVER, THE CALL CAN 
	ONLY BE STAISFIED BY SOME DEVICE TRANSFER, INCLUDING REFILLING
	OR EMPTYING THE BUFFER IN READINESS FOR THE NEXT READ OR WRITE
	THE PROCESSOR WILL INITIATE THE NECESSARY DEVICE ACTION (OR
	HAVE ITS REQUEST QUEUED SHOULD THE DEVICE BE OTHERWISE ENGAGED).
	THE DEVICE WILL RECALL THE READ-WRITE PROCESSOR ON INTERRUPT;
	IN THE MEANTIME, CONTROL WILL BE RESTORED TO THE USER PROGRAM
	TO ENABLE ALTERNATIVE PROCESSING BUT THE DATA-SET WILL REMAIN
	BUSY.  FOLLOWING EACH READ OR WRITE CALL, THE USER PROGRAM
	MUST, THEREFORE, ENSURE THAT THE DATA-SET IS FREE (BY MEANS
	OF A WAIT OR WAITR CALL*) BEFORE ACCESSING THE LINE BUFFER.
	THIS WILL APPLY NOT ONLY TO THE DATA IN THE LINE BUT ALSO TO
	THE HEADER WORDS AS THE PROCESSOR WILL USE THESE TO STORE
	INFORMATION TEMPORARILY WHILE THE DEVICE IS OPERATING.

	*ALTHOUGH ANY SUBSEQUENT CALL FOR AN OPERATION UPON THE SAME
	DATASET WILL CAUSE AN IMPLIED WAIT IF THE DATA-SET IS BUSY,
	SUCH CALL MAY CORRUPT INFORMATION BEING RETURNED TO THE USER
	BY THE PROCESSOR UNLESS CAUTION IS OBSERVED.


8.4.4	INIT

	CALL SEQUENCE

		MOV	#LINKBLOCK,-(SP)
		EMT	6

	THE INIT FUNCTION IS TO ESTABLISH A DATASET.  SEE SECTION 6
	FOR A DETAILED DESCRIPTION.

8.4.5	RELEASE

	CALLING SEQUENCE

		MOV	#LINKBLOCK,-(SP)
		EMT	7

	THE RELEASE FUNCTION IS THE INVERSE OF THE INIT FUNCTION.
	(SEE SECTION 6).  THE USER ISSUES THE RELEASE CALL FOR A 
	DATASET WHEN ALL ACTION UPON THE DATASET IS COMPLETE.

8.4.6	TRAN

	CALLING SEQUENCE

	MOV	MOV	#TRANBLOCK,-(SP)
		MOV	#LINKBLOCK,-(SP)
		EMT	10

	THE TRAN PROCESSOR ALLOWS THE USER PROGRAM DIRECT ACCESS TO 
	PHYSICAL DEVICES.  THE PROCESS AS WELL AS THE REQUIRED TRAN-
	BLOCK ARE COVERED IN SECTION 6.7.

8.4.7	BLOCK

	NOT YET AVAILABLE (EMT 11)

8.4.8	SPECIAL FUNCTIONS

	EMT 12 WILL ALLOW THE USER TO REQUEST THE MONITOR TO PERFORM
	SPECIAL DEVICE FUNCTIONS, SUCH AS A REWIND MAGNETIC TAPE.  THE
	FORMAT OF THIS CALL WILL BE DETERMINED LATER.

8.4.9	STATUS

	CALLING SEQUENCE

		MOV	#LINKBLK,-(SP)
		EMT	13

	THE USER MAY MAKE USE OF THE STATUS CALL TO DETERMINE 
	CHARACTERISTICS OF THE DEVICE TO WHICH THE DATASET REPRE-
	SENTED BY THE LINKBLK IS ASSOCIATED (BY AN INIT).  THE MONITOR
	REUTRNS THE FOLLOWING INFORMATION ON THE TOP OF THE STACK:

		(SP)	FACILITIES WORD FROM DRIVER
			DEVICE NAME
			BUFFER SIZE

	THE DRIVER FACILITIES WORD HAS THE FOLLOWING FORMAT:

		BIT(ON)	    INTERPRETATION

		   0	    DEVICE WILL SUPPORT MULTI-DATASET ACTIVITY
		   1	    DEVICE WILL HANDLE OUTPUT
		   2	    DEVICE WILL HANDLE INPUT
		   3	    DEVICE WILL HANDLE ASCII DATA
		   4	    DEVICE WILL HANDLE BINARY DATA
		   5	    DRIVER HAS A SPECIAL FUNCTIONENTRY
		   6	    DRIVER HAS A CLOSE ENTRY
		   7	    DRIVER HAS AN OPEN ENTRY
		8-13	    SPARE
		  14	    DEVICE IS DECTAPE
		  15	    DEVICE IS FILE STRUCTURED

8.4.10	DIRECTORY SEARCH

	THIS ROUTINE IS CALLED WHENEVER THE USER NEEDS TO ASCERTAIN
	THE EXISTENCE OF A PARTICULAR FILE.

	CALLING SEQUENCE

		MOV	#FILEBLOCK,-(SP)
		MOV	#LINKBLOCK,-(SP)
		EMT	14

	UPON RETURN THE TOP OF THE STACK APPEARS AS:

		-1...FILE DOESN'T EXIST
		 0...FILE EXISTS
		 1...FILE IS OPEN FOR OUTPUT

8.4.11	ALLOCATE

	CALLING SEQUENCE

		MOV	#NUMBER,-(SP)
		MOV	#FILEBLOCK,-(SP)
		MOV	#LINKBLOCK,-(SP)
		EMT	15

	THE ALLOCATE COMMAND IS USED WHEN A USER WANTS TO CREATE 
	A CONTIGUOUS FILE.  TO DO SO, HE MUST KNOW THE SIZE OF THE 
	FILE HE NEEDS; THIS SIZE IS THEN REPRESENTED AS THE NUMBER
	OF 64 WORD UNITS COMPRISING THE FILE AND IS THE "NUMBER"
	REFERRED TO IN THE CALLING SEQUENCE ABOVE.  IN ATTEMPTING TO 
	ALLOCATE A CONTIGUOUS AREA TO A FILE, THE FILE MANAGES TO 
	BEGIN SCANNING THE BIT MAP AT THE HIGH END.  IF THE REQUIRED
	NUMBER OF BLOCKS WAS NOT FOUND, THE ERROR RETURN INDICATED 
	IN THE FILE NAME BLOCK IS TAKEN AND NO FILE IS CREATED.  IF
	THE REQUIRED BLOCKS ARE FOUND, THE CORRESPONDING BITS ARE SET
	TO "OCCUPIED" IN THE BIT MAP AND THE FILE IS ENTERED INTO 
	THE APPROPRIATE USER FILE DIRECTORY.

8.4.12	CLOSE

	CALLING SEQUENCE

		MOV	#LINKBLOCK,-(SP)
		EMT	17

	THE COUNTERPART OF THE OPEN COMMAND IS CLOSE.  WHEN THE FILE
	IS OPENED ALL PERTINENT DATA REGARDING THE FILE IS STORED 
	IN THE FIB OR IN THE DIRECTORY ENTRY ITSELF.  CLOSING THE FILE
	IS DISCUSSED IN SECTION 6.

8.4.13	RENAME

	CALLING SEQUENCE

		MOV	#NEWNAME,-(SP)
		MOV	#OLDNAME,-(SP)
		MOV	#LINKBLOCK,-(SP)
		EMT	20

	THE RENAME FUNCTION IS USED WHENEVER THE OWNER OF A FILE FINDS
	IT NECESSARY TO CHANGE THE NAME OR THE PROTECTION CODE.
	IN CALLING RENAME, THE OWNER PUSHES THE ADDRESSES OF TWO FILE
	NAME BLOCKS, THE FIRST CONTAINING THE NEW FILE NAME AND PRO-
	TECTION, THE SECOND CONTAINING THE OLD.

8.4.14	DELETE

	CALLING SEQUENCE

		MOV	#FILEBLOCK,-(SP)
		MOV	#LINKBLOCK,-(SP)
		EMT	21

	THE DELETE COMMAND IS USED WHEN A USER WISHES TO REMOVE A 
	FILE FROM HIS DIRECTORY AREA AND RETURN THE BLOCKS IT OCCUPIED
	TO THE FREE POOL.  ONLY AUTHORIZED USERS CAN DELETE A FILE.

8.4.15	APPEND

	CALLING SEQUENCE

		MOV	#FILEBLOCKA,-(SP)
		MOV	#FILEBLOCKB,-(SP)
		MOV	#LINKBLOCK,-(SP)
		EMT	22

	APPEND IS CALLED WHEN A USER FINDS IT NECESSARY TO APPEND 
	ONE LINKED FILE TO ANOTHER.  THE ODER OF THE ARGUMENTS IS
	APPEND FILEA TO FILEB.

8.4.16	GARBAGE COLLECT DIRECTORY (EMT 23)

	NOT YET AVAILABLE.


8.4.17	PROTECT

	CALLING SEQUENCE

		MOV	#FILEBLOCK,-(SP)
		MOV	#LINKBLK,-(SP)
		EMT	24

	THE PROTECT FUNCTION IS USED TO SET BIT 7 IN THE PROTECT BYTE
	OF THE FILES DIRECTORY ENTRY.  THIS WILL PREVENT THE FILES AUTOMATIC
	DELETION UPON FINISH.

8.4.18	SPARES

	EMT CODES 25-27 ARE NOT YET ASSIGNED.

8.4.19	RESERVED

	EMT CODES 30-32 ARE RESERVED FOR INTERNAL MONITOR COMMUNICATION.

8.4.20	EXIT

	CALLING SEQUENCE

		EMT 33

	THE USER PROGRAM CALLS EXIT TO INFORM THE MONITOR THAT ALL OF
	THE PROGRAMS FUNCTIONS HAVE BEEN COMPLETED.  THE MONITOR INSURES
	THAT ALL OF THE PROGRAMS DATA FILES HAVE BEEN CLOSED AND, IN
	GENERAL, PREPARES FOR THE NEXT KEYBOARD REQUEST.

8.4.21	RESERVED

	EMT CODES 34-40 ARE RESERVED FOR MONITOR INTERNAL COMMUNICATION.

8.4.22	GENERAL UTILITIES

	THE GENERAL UTILITIES PACKAGE OF THE PDP-11 DISK MONITOR
	IS PROVIDED AS A MEANS FOR THE USER TO COMMUNICATE INFORMATION TO
	THE MONITOR (RESTART ADDRESS, ETC.) OR OBTAIN INFORMATION FROM
	THE MONITOR (CORE SIZE, ETC.).  THESE VARIOUS FUNCTIONS HAVE BEEN
	GROUPED UNDER ONE EMT CODE, AND THE CALLER PUSHED AN IDENTIFIER 
	ONTO THE STACK TO INDICATE THE DESIRED FUNCTION.  THUS, THROUGH
	USE OF THESE FUNCTIONS THE USER NEED NOT DIRECTLY ALTER ANY
	MONITOR INFORMATION.

	DETAILED DESCRIPTION

	THE DESCRIPTION OF EACH FUNCTION PROVIDED IS GIVEN BELOW:

	SET TRAP VECTOR

	THIS ROUTINE SETS THE TRAP (34(8)) VECTOR TO CONTAIN THE FURN-
	ISHED INFORMATION.  THE CALLING SEQUENCE IS:

		MOV	#ADDR,-(SP)	;DESIRED TRAP ADDRESS
		MOV	#STATUS,-(SP)	;DESIRED STATUS
		MOV	#1,-(SP)	;IDENTIFIER
		EMT	41

	SET RESTART ADDRESS

	THE ADDRESS TO BE USED IN RESPONSE TO A KEYBOARD COMMAND IS SET
	BY THE FOLLOWING MONITOR CALL:

		MOV	#ADDR,-(SP)	;DESIRED RESTART ADDRESS
		MOV	#2,-(SP)	;IDENTIFIER
		EMT	41

	OBTAIN CORE SIZE

	THE USER MAY OBTAIN THE ADDRESS OF THE "HIGHEST" WORD IN THE
	OPERATIONAL MACHINE MEMORY (CORE SIZE -2. I.E. AN 8K MACHINE
	WOULD GIVE 37777(8)) BY THE FOLLOWING CALLING SEQUENCE:

		MOV	#100,-(SP)	;IDENTIFIER
		EMT	41

	UPON RETURN THE TOP OF THE STACK WILL CONTAIN THE REQUESTED VALUE.

	OBTAIN PERMANENT MONITOR SIZE.

	THE GENERATED SIZE (STATUS) OF THE RESIDENT MONITOR CAN BE 
	OBTAINED BY THE FOLLOWING:

		MOV	#101,-(SP)	;CODE
		EMT	41

	THE VALUE IS RETURNED ON TOP OF THE STACK.

	OBTAIN THE FULL MONITOR SIZE.

	THE TOTAL MONITOR AREA INCLUDING BUFFER AND TRANSIENT AREAS (ALL
	CURRENT AT TIME OF CALL) IS RETURNED ON TOP OF THE STACK BY THE
	CALL:

		MOV	#102,-(SP)	;IDENTIFIER
		EMT	41


	OBTAIN DATE

	THE MONITOR CURRENT DATE WORD (ACCURATE OR NOT) IS RETURNED ON
	TOP OF THE STACK BY:

		MOV	#103,-(SP)
		EMT	41

	OBTAIN TIME OF DAY

	THE TWO CURRENT TIME CELLS (TIME GIVEN IN TICKS) ARE RETURNED ON
	THE STACK (LEAST SIGNIFICANT ON TOP OF STACK) BY THE CALL:

		MOV	#104,-(SP)	;IDENTIFIER
		EMT	41

8.4.23	GENERAL CONVERSIONS

	EMT 42 WILL PROVIDE A VARIETY OF GENERAL DATA CONVERSIONS, SUCH
	AS OCTAL TO ASCII, RADIX 40 PACKING, ETC.  MORE DETAIL IS NOT
	YET AVAILABLE.

8.4.24	RESERVED

	EMT CODES 43 THROUGH 55 ARE RESERVED FOR INTERNAL MONITOR
	COMMUNICATION.

8.4.25	SPARES

	EMT CODES 56 THRU 77 ARE RESERVED FOR FUTURE EXPANSION.

	IN ADDITION TO THE EMT INSTRUCTION AS DISCUSSED ABOVE,
	THE DISK MONITOR SYSTEM RESERVES THE IOT INSTRUCTION FOR
	ITS EXCLUSIVE USE.

9.0	OPERATING PROCEDURES

9.1	DELIVERY FORM

	THE DISK MONITOR WILL BE DELIVERED TO THE USER ON EITHER
	PAPER TAPE OR DECTAPE.  AS DELIVERED THE MONITOR WILL
	CONSIST OF A BINARY VERSION OF A MINIMAL MONITOR AND
	BINARY VERSIONS OF ALL INFLEXIBLE (NON-CHANGING) MODULES
	AS WELL AS SYMBOLIC VERSIONS OF ALL FLEXIBLE MODULES.
	A LOAD VERSION OF THE SYSTEM LOADER PROGRAM IS ALSO
	PROVIDED TO FACILITATE LOADING THE SYSTEM ONTO DISK.

	TO INITIATE THE OPERATION OF THE MONITOR THE USER SIMPLY
	LOADS THE MONITOR BINARIES ONTO DISK AS DELIVERED USING THE
	SYSTEM LOADER PROVIDED AND FOLLOWS NORMAL SYSTEM STARTUP
	PROCEDURES.  THE USER MAY THEN USE THE DELIVERED SYSTEM
	TO GENERATE A MONITOR TO SATISFY HIS OWN NEEDS.

9.2	EXTERNAL CONTROL
	
	NORMAL EXTERNAL CONTROL OF THE MONITOR WILL BE THROUGH
	THE TELETYPE/KEYBOARD.  THE OPERATOR MAY REQUEST THAT 
	THE MONITOR ACCEPT COMMANDS FROM ANOTHER EXTERNAL DEVICE,
	HOWEVER.

9.3	EXTERNAL SWITCHES/INDICATORS

	THE DISK MONITOR ITSELF DOES NOT DEPEND UPON ANY CONSOLE
	SWITCH SETTINGS NOR DOES IT MAKE ANY ATTEMPT TO COMMUNICATE
	WITH THE USER THROUGH THE CONSOLE INDICATORS.  HOWEVER, A
	USER PROGRAM RUNNING UNDER THE MONITOR MAY MAKE USE OF THESE
	MEDIA.

9.4	ACCESS

	IF ANY ACESS RESTRAINTS ARE IMPOSED THEY WILL BE IMPOSED
	BY A USER WRITTEN ACCOUNTING ROUTINE.  THE DISK MONITOR
	WILL PROVIDE "EXITS" SO THAT THE USER CAN INSERT SUCH A 
	ROUTINE.

9.5	LOADING

	TO LOAD THE MONITOR INTO CORE FROM THE DISK THE OPERATOR
	SIMPLY USES THE DIODE ROM BOOTSTRAP LOADER TO BOOTSTRAP THE
	MONITOR INTO CORE FROM THE DISK.  THIS CAUSES THE RESIDENT
	MONITOR AND INITIALIZATION ROUTINE TO BE LOADED FROM THE
	DISK AND THE INITIALIZATION ROUTINE TO BEGIN EXECUTION.

	WHEN THE INITIALIZATION IS COMPLETE, THE DISK MONITOR WILL
	BE READY TO ACCEPT A KEYBOARD COMMAND.  THE OPERATOR MAY
	ENTER THE CURRENT DATE AND TIME (IF HE DESIRES) THROUGH
	USE OF THE APPROPRIATE KEYBOARD COMMAND (SEE SECTION 8.3).

9.6	STARTING

	THE START UP PROCEDURE IS AUTOMATIC AS IS DEFINED ABOVE
	IN SECTION 9.5.

9.7	RESTARTING

	THE CAPABILITY TO RESTART ANY PROGRAM RUNNING UNDER THE 
	DISK MONITOR IS PROVIDED (SEE SECTION 8.3).  THE CAPABILITY
	FOR RESTARTING THE MONITOR ITSELF WILL NOT BE PROVIDED IN
	THIS INITIAL VERSION OF THE MONITOR, HOWEVER, CONSIDERATION
	FOR INCLUDING RECOVERY IN THE FUTURE VERSIONS WILL BE MADE
	IN THE DESIGN OF THIS VERSION.  IT SHOULD BE NOTED, HOWEVER,
	THAT "BOOTING" THE MONITOR DOES NOT ALTER ANY FILES ON ANY
	DEVICE.

9.8	TERMINATING

	PROGRAMS OPERATING UNDER CONTROL OF THE DISK MONITOR
	MAY BE TERMINATED UNDER EITHER OPERATOR OR PROGRAM CONTROL.
	THE OPERATOR MAY TERMINATE A PROGRAM BY USE OF THE KILL
	COMMAND.  A RUNNING PROGRAM TERMINATES ITSELF (I.E. SIGNALS
	THAT IT HAS COMPLETED PROCESSING) VIA THE "EXIT" EMT CALL.


9.9	SYSTEM GENERATION

	TO GENERATE A MONITOR, THE MRT TABLE AND THE DDL TABLE ARE
	THE ONLY TABLES REQUIRING MODIFICATION.  BECAUSE OF INITIAL-
	IZATION THE MRT TABLE WILL BE CORRECTLY MODIFIED UPON EVERY
	LOAD OF THE MONITOR.  THE DDL, HOWEVER, WILL REQUIRE THE
	ADDITION OR DELETION OF ENTRIES SO THAT IT WILL CORRESPOND
	DIRECTLY WITH THE PARTICULAR CONFIGURATION'S PERIPHERAL
	DEVICES.  AFTER ASSEMBLY OF THE DDL THE USER MERELY SUPPLIES
	THE LINKER WITH THE MODULES THAT HE WISHES TO BE RESIDENT
	AND USES SYSLOAD TO PLACE THE NON-RESIDENT MODULES ON DISK.

9.10	ERROR CONDITIONS

	THE MONITOR WILL PROVIDE CENTRALIZED PRINTING OF
	DIAGNOSTIC MESSAGES FOR MONITOR ROUTINES.  SYSTEM
	COMPONENTS LIKE COMPILERS AND ASSEMBLERS WILL BE
	EXPECTED TO CONTAIN THEIR OWN DIAGNOSTIC MESSAGES
	FOR ERRORS DETECTED DURING THEIR PROCESSING, BUT THEY
	MAY RELY ON THE CENTRALIZED DIAGNOSTIC ROUTINE FOR 
	PRINTING OF RUN-TIME MESSAGES,E.G. THE FORTRAN OBJECT
	PROGRAM WILL USE THE CENTRAL MESSAGE WRITER TO PRINT
	AN ARITHMETIC OVERFLOW DIAGNOSTIC.

	TO REQUEST THAT A DIAGNOSTIC MESSAGE BE PRINTED A 
	ROUTINE WILL TRAP (IOT) TO THE DIAGNOSTIC PRINTING
	ROUTINE WITH A ONE WORD ARGUMENT ON TOP OF THE STACK:

				MESSAGE
			CODE	NUMBER
			15  87		0

	THE LOW ORDER BYTE WILL GIVE A MESSAGE NUMBER.  EACH
	SUCH NUMBER WILL CORRESPOND TO A CONCISE ENGLISH LANGUAGE
	TEXT STORED ON DISK.  THE HIGH ORDER BYTE WILL BE A CODE 
	WHICH WILL GIVE THE TYPE OF THE MESSAGE ACCORDING TO THE
	FOLLOWING TABLE:

		XXXXXX00(2)	IMPLIES MESSAGE IS INFORMATIONAL
		XXXXXX10(2)	IMPLIES MESSAGE IS A WARNING
		XXXXXX01(2)	IMPLIES MESSAGE REQUESTS OPERATOR 
				ACTION
		XXXXXX11(2)	IMPLIES THAT THE MESSAGE IS A FATAL
				DIAGNOSTIC

	ONE ADDITIONAL WORD OF INFORMATION MAY BE
	PLACED ON THE STACK PRIOR TO THE ERROR CODE.

	THE DIAGNOSTIC PRINT MODULE WILL LOOK UP THE MESSAGE IN THE
	DISK FILE, PRINT THE TEXT AND TAKE APPROPRIATE ACTION DEPEND-
	ING ON THE CODE OF THE LOW BITS.  THE ADDITIONAL WORDS OF
	INFORMATION WILL ALSO BE DISPLAYED FOR THE OPERATOR, HENCE
	THEY WILL BE USEFUL FOR SUCH INFORMATION AS CALL ERROR
	ADDRESS, STATUS,ETC.

	THE MAXIMUM TEXT SIZE WILL BE 16 CHARACTERS.  THUS, IF 128
	MESSAGES ARE REQUIRED, 1K WORDS OF DISK WILL BE USED (LOW
	MESSAGE NUMBERS WILL BE USED FIRST SO THAT ONLY THE ACTUAL 
	REQUIREMENT FOR DISK SPACE WILL BE USURPED).  IF THE
	AMOUNT OF DISK SPACE BECOMES CRITICAL, THE ENGLISH TEXT WILL
	BE DROPPED IN FAVOR OF NUMBERED MESSAGE PRINTOUT ONLY.  IT
	SHOULD BE POINTED OUT THAT A MESSAGE RENUMBERING MIGHT BE
	REQUIRED IF A CHANGE-OVER OCCURS SO THAT LOGICALLY RELATED
	MESSAGES WOULD HAVE LOGICALLY RELATED NUMBERS.

	ERROR MESSAGES AND RELATED INFORMATION ARE AS FOLLOWS:


	CODE	NUMBER		MESSAGE		ADDITIONAL INFORMATION
	----	------		-------		----------------------

	 0	  0	    SYSTEM DISK FAILURE

	 1	  1	    DISK ADDRESS ERROR	STATUS,CALL ADDRESS
	 3	  0	    DATASET NOT INIT	CALL ADDRESS

	 3	  1	    STACK OVERFLOW	CALL ADDRESS

	 3	  2	    INVALID CALL	CALL ADDRESS
	 1	  2	    DEVICE NOT RDY

	 3	  3	    INVALID FUNCTION

	 1	  3	    NO DEVICE		LINK BLOCK ADDRESS
	 3	  4	    ILLEGAL DEVICE	DEVICE NAME

	 3	  5	    RELEASE ERROR	CALL ADDRESS

	 3	  6	    DEVICE FULL		CALL ADDRESS

	 3	  7	    NO BUFFER SPACE	CALL ADDRESS

	 3	 10	    ILLEGAL R/W		CALL ADDRESS

	 3	 11	    ILLEGAL OPEN	CALL ADDRESS

	 3	 12	    INVALID OPEN	CALL ADDRESS

	 3	 13	    ILLEGAL INIT	DEVICE, CALL ADDRESS

	 3	 14	    BIT MAP FAILURE	CALL ADDRESS

	 3	 15	    DECTAPE (N.E.M OR E.Z.) CALL ADDRESS, STATUS

	 1	  4	    DECTAPE(H/W FAIL)	CALL ADDRESS, STATUS


	READ/WRITE ERRORS

	AT ANY READ OR WRITE CALL, THREE TYPES OF ERROR SITUATION ARE
	ENVISAGED:

	A)  FATAL ERRORS: IF THE USER SPECIFIES A MODE OR FUNCTION
	    WHICH IS GENERALLY ILLEGAL OR IS INVALID FOR THE DEVICE
	    CONCERNED, THIS WILL BE CONSIDERED A PROGRAM ERROR RESULT-
	    ING IN AN EXIT TO THE ERROR DIAGNOSTIC PRINT ROUTINE.
	    RECOVERY IN THIS CASE MAY BE POSSIBLE BY RESTARTING THE
	    PROGRAM, (ASSUMING THAT THE ERROR CAN BE CORRECTED BY
	    OPERATOR ACTION SUCH AS ASSIGNING A MORE SUITABLE DEVICE).

	B)  SEMI-FATAL ERRORS: AS HAS BEEN NOTED, READ-WRITE PROCESS-
	    ING REQUIRES AN INTERNAL BUFFER FOR THE DATA-SET CONCERNED.
	    IF THE READ-WRITE PROCESSOR IS OBLIGED TO CLAIM SUCH BUFFER
	    AND THERE IS INSUFFICIENT FREE CORE, IT WILL ATTEMPT TO TAKE
	    AN ERROR RETURN TO THE USER, USING A WORD PRESCRIBED FOR THE
	    PURPOSE IN THE DDB LINK-BLOCK IN THE PROGRAM (THE USER MAY
	    WISH TO SET THIS SPECIFICALLY FOR READ-WRITE RETURNS AS OPPOSED
	    TO THOSE FOLLOWING INIT OR OPEN).  IF, HOWEVER, THIS
	    WORD IS SET TO 0, THE ERROR WILL BE TREATED AS FATAL
	    RESULTING IN ERROR DIAGNOSTIC PRINTING.

	C)  PROGRAMMABLE ERRORS: PROVIDED THAT THE READ-WRITE 
	    PROCESSOR IS ABLE TO BEGIN THE TRANSFER, THE ONLY ERRORS 
	    WHICH MAY SUBSEQUENTLY ARISE ARE THOSE WHICH PREVENT THE
	    SATISFACTORY COMPLETION OF THAT TRANSFER.  SUCH ERRORS
	    WILL BE SIGNALLED TO THE USER BY MEANS OF THE STATUS
	    BYTE IN THE SECOND HEADER WORD.  THE BITS OF THIS BYTE WILL BE 
	    CODED AS FOLLOWS:


	DEVICE				CHARACTER	CHECKSUM	SHORT OR
	PARITY	E.O.M.	E.O.F.		PARITY		ERROR		TRUNCATED
	FLAG				ERROR				LINE


	THE SIGNIFICANCE OF THESE ERRORS IS NOTED BELOW.

	1)  DEVICE PARITY: PARITY OR POSSIBLY TIMING FAILURES ON MAGNETIC
	    DEVICES WILL BE FOLLOWED INITIALLY BY ABOUT 8 OR 9 REPEAT
	    ATTEMPTS TO COMPLETE THE TRANSFER SATISFACTORILY. IF
	    EVEN THESE FAIL, THE APPROPRIATE DRIVER
	    WILL SET A FLAG IN THE DDB AND ENDEAVOR, IF NECESSARY, TO
		CONTINUE BEYOND THE FAILURE POINT TO THE END OF THE BLOCK
		REQUESTED.  THE FLAG WILL BE PASSED ON TO THE USER BUT
		IT NEED NOT, OF COURSE, APPLY TO THE ONE CURRENTLY BEING PROCESSED;
		IT WILL MERELY SERVE AS A WARNING THAT THIS OR SUBSEQUENT 
		DATA MAY BE DUBIOUS.  (IN FORMATTED OPERATIONS, THE INVALID
		DATA WILL PROBABLY CAUSE OTHER ERRORS TO BE SEEN ALSO.)
		THE FLAG WILL BE RETURNED TO THE USER AS LONG AS THE SAME
		DATA BLOCK IS BEING USED.


	    2)	END OF MEDIUM (E.O.M.)  THIS WILL NORMALLY OCCUR 
		BECAUSE AN INPUT DEVICE CANNOT SUPPLY SUFFICIENT DATA TO 
		FILL ITS ALLOTTED BUFFER (EXPECTED AT THE END OF A 
		CARD-DECK OR PAPER-TAPE THOUGH POSSIBLE ALSO IF A PAPER
		TAPE IS TORN). THE SAME FLAG MAY ALSO INDICATE THAT
		THERE IS NO MORE ROOM ON A BULK-STORAGE DEVICE.  (NON-BULK
		STORAGE OUTPUT DEVICE DRIVERS WILL THEMSELVES SIGNAL
		"DEVICE NOT READY" TO THE OPERATOR AND THE READ-WRITE
		PROCESSOR NEED NOT KNOW THIS HAS HAPPENED.)

	    3) 	END OF FILE (E.O.F.).  THIS WILL BE SIGNALLED EITHER
		BECAUSE THE LAST BLOCK OF AN INPUT LINKED FILE HAS BEEN
		PROCESSED OR WHEN THAT FOR A CONTIGOUSLY ALLOCATED FILE
		HAS BEEN READ OR WRITTEN.

		(BOTH EOM AND EOF MAY BE ACCOMPANIED BY OTHER ERROR
		SITUATIONS WHICH WILL BE FLAGGED ACCORDINGLY - IN
		PARTICULAR THE USER'S LINE REQUIREMENTS MAY HAVE NOT
		BEEN COMPLETELY SATISFIED AT THIS POINT SO THE SHORT-LINE
		MARKER MAY ALSO BE SET.  MOREOVER ALL SUBSEQUENT CALLS
		FOR READ OR WRITE WILL ALWAYS RESULT IN AN IMMEDIATE RETURN
		TO THE USER WITH BOTH SHORT-LINE AND THE APPROPRIATE END
		ERROR SIGNALLED.)

	    4)  CHARACTER PARITY.  APPLICABLE ONLY ON PARITY ASCII
		INPUT, THIS BIT WILL SIGNIFY THAT SOME CHARACTER OR
		CHARACTERS ARE IN ERROR.  AS MENTIONED EARLIER, THESE
		CHARACTERS WILL BE INDIVIDUALLY MARKED BY THE PRESENCE
		OF BIT 7.

	    5)	CHECKSUM ERROR. THIS WILL OCCUR ONLY ON FORMATTED BINARY
		INPUT AND WILL SIGNIFY A DISCREPANCY BETWEEN THE SUM
		ACCUMULATED DURING THE INPUT TRANSFER AND THAT STORED
		WITH THE DATA.

	    6)	SHORT OR TRUNCATED LINE.  IN GENERAL, THIS FLAG WILL BE
		RETURNED WHENEVER THE READ-WRITE PROCESSOR HAS BEEN UN-
		ABLE TO SATISFY THE USER'S REQUIREMENTS ENTIRELY.  FOR
		ALL MODES, IT WILL SIGNIFY THAT THE USER HAS OMMITTED TO
		SPECIFY THE REQUIRED BYTE-COUNT AND NO TRANSFER HAS
		THEREFORE BEEN MADE; IT WILL ALSO ACCOMPANY EOM OR EOF
		IF THE LINE IS NOT COMPLETE IN ACCORDANCE WITH THE
		SPECIFICATION FOR THE MODE.  FOR FORMATTED ASCII, IN
		PARTICULAR, IT MAY ALSO MEAN THAT THE BYTE-COUNT HAS
		RUN-OUT BEFORE THE REQUISITE LINE DELIMITER HAS BEEN
		SEEN ON INPUT OR OUTPUT AND THE TRANSFER HAS THEREFORE
		BEEN PREMATURELY TERMINATED.  A SIMILAR TRUNCATION
		ERROR WILL OCCUR WHENEVER A FORMATTED BINARY LINE
		IS LONGER THAN THE AVAILABLE INPUT LINE WILL ALLOW.
		(IN THIS CASE THE USER MAY WISH TO SWITCH TO UNFORMATTED
		BINARY OPERATIONS TO ACCESS THE REST OF THE LINE
		THOUGH OF COURSE NO CHECKSUM VERIFICATION WILL THEN
		BE POSSIBLE.)


	FILE STRUCTURE ERRORS
		GENERAL FILE STRUCTURES ERRORS ARE INDICATED
		IN THE FILE NAME BLOCK.  WHEN AN ERROR IS
		DETECTED AN ERROR CODE IS MOVED TO LOCATION FILE NAME
		BLOCK -1, AND CONTROL IS RETURNED TO THE USER AT THE
		ERROR RETURN ADDRESS INDICATED AT FILE NAME BLOCK -4.
		(IF THE ERROR ADDRESS IS 0, A FATAL ERROR MESSAGE TO THE
		OPERATOR WILL RESULT)

		THE ERROR CODES AND THEIR DEFINITIONS ARE:

		1	UNUSED

		2	FILE DOESN'T EXIST
			FILE ALREADY EXISTS

		3	USAGE COUNT EQUALS 76 OR 77

		4	ATTEMPT TO OPEN A LOCKED FILE FOR UPDATE OR
			EXTENSION.

		5	ILLEGAL REQUEST TO A CONTIGUOUS FILE

		6	IMPROPER ACCESS PRIVILEGE (PROTECTION VIOLATION)

		7	UNUSED

		10	OPENC REQUEST TO A LINKED FILE

		11	A FILE IS ALREADY OPEN FOR OUTPUT OR EXTENSION
			ON THIS DT UNIT

		12	DT DIRECTORY FULL

		13	USER OTHER THAN THE OWNER ATTEMPTED TO WRITE ON
			THIS DT UNIT

		14	ILLEGAL ACTION TO AN OPENED FILE

		15	ILLEGAL FILE NAME



10.0	PHYSICAL DESCRIPTION AND ORGANIZATION

10.1	SIZE

10.1.1	CORE RESIDENT SIZE

	THE SIZE OF THE MINIMAL RESIDENT MONITOR WHICH IS 
	REQUIRED FOR NORMAL SYSTEM FUNCTIONS WILL BE 1000
	WORDS.  TO IMPROVE SYSTEM OPERATION THE USER MAY
	CHOOSE TO INCREASE HIS RESIDENT MONITOR SIZE BY 
	SELECTING ADDITIONAL ROUTINES TO BE CORE RESIDENT.

10.1.2	DISK SPACE REQUIRED

	NOT YET AVAILABLE.

10.2	LAYOUT

10.2.1	CORE LAYOUT

			   NK
		USER
		AREA


		STACK


		BUFFER
		AREA


		RESIDENT
		MONITOR

			   400(8)

		INTERRUPT
		VECTORS
			   0

	THE ABOVE CORE LAYOUT WILL BE THE ONE USED FOR THE
	PDP-11 DISK MONITOR.  THE MONITOR AND USER AREAS ARE
	SEPARATED BY THE DYNAMICALLY FLEXIBLE STACK AND BUFFER
	AREAS.  THE REASON FOR THIS ARRANGEMENT IS THAT BY 
	SEPARATING THE USER FROM THE MONITOR, USER PROGRAMS WILL
	NOT REQUIRE RE-LINKING FOR EVERY CHANGE IN THE MONITOR.
	WITH A MONITOR WHICH IS AS FLEXIBLE AS THE DISK MONITOR,
	IT IS FELT THAT MONITOR SIZE WILL CHANGE MUCH MORE OFTEN
	THAN WILL A MACHINE'S CORE SIZE.

10.2.2	RESIDENT MONITOR LAYOUT

	THE RESIDENT MONITOR WILL BE CONFIGURED AS SHOWN IN
	PARAGRAPH 11.1.1.  THE USER MAY INCLUDE ANY MONITOR
	ROUTINES IN THE PERMANENTLY RESIDENT CORE LOAD THAT
	HE WISHES AND CAN AFFORD THE SPACE FOR.  A DETAILED 
	EXPLANATION OF THE FUNCTIONS OF RESIDENT MONITOR 
	ROUTINES APPEARS IN SECTION 11.

11.0	FUNCTIONAL DESCRIPTION

11.1	RESIDENT MONITOR

11.1.1	MONITOR CONFIGURATION

	THE RESIDENT MONITOR WILL BE CONFIGURED AS FOLLOWS:

	    ERROR HANDLING AND
	    BUFFER MANAGEMENT
		  TABLE

	    ADDITIONAL RESIDENT
	     ROUTINES (AT USER
		OPTION)

	    MINIMAL TELETYPE
		DRIVER

	    RESIDENT DISK
	       DRIVER

	    BUFFER MANAGER

	    QUEUE MANAGER

	    SWAP AREA MANAGER
	     AND SWAP BUFFER

	    EMT HANDLER

	    DEVICE DRIVER
	       LIST

	    MONITOR RESIDENT
		TABLE

	    SYSTEM VECTOR TABLE
				       400(8)

	THE USER MAY INCLUDE ANY MONITOR ROUTINES IN THE PERMANENTLY
	RESIDENT CORE LOAD THAT HE WISHES AND CAN AFFORD THE SPACE FOR.

	THE ROUTINES AND TABLES SHOWN ARE THE MINIMAL REQUIRED RESIDENT
	MONITOR.  THE FUNCTION OF EACH AREA IS DESCRIBED BELOW.

(11.1.1 CONT'D)

	SYSTEM VECTOR TABLE (SVT) - THE SYSTEM VECTOR TABLE PROVIDES THE
	RESIDENT MONITOR COMMUNICATION AREA.  THIS TABLE WILL CONTAIN
	SUCH VALUES AS:

		DATE
		TIME OF DAY
		FIXED POINT RESTART ADDRESS (OR
		  BEGINNING OF PROGRAM) FOR THE
		  OPERATING PROGRAM
		MAXIMUM CORE SIZE
		INTERNAL COMMUNICATION INFORMATION

	VARIABLE INFORMATION IN THIS TABLE IS BUILT BY THE INITIALIZATION
	ROUTINE IMMEDIATELY FOLLOWING BOOTSTRAP.

	MONITOR RESIDENT TABLE (MRT) - THE MONITOR RESIDENT TABLE (MRT)
	WILL CONSIST OF ONE WORD FOR EACH MONITOR ROUTINE.  THE TABLE
	IS ARRANGED TO CORRESPOND ORDERWISE TO THE EMT CODE USED TO
	CALL EACH ROUTINE.  FOR EACH RESIDENT ROUTINE, THE MRT ENTRY
	WILL GIVE ITS CORE ADDRESS.  FOR NON-RESIDENT ROUTINES THE
	MRT ENTRY IS FILLED IN BY INITIALIZATION TO SHOW BOTH THE
	DISK ADDRESS AND LENGTH OF THE ROUTINE.  UNAVAILABLE ROUTINES
	ARE SO INDICATED BY A WORD EQUAL TO 1.

	DEVICE DRIVER LIST (DDL) - THE DEVICE DRIVER LIST CONTAINS 
	ONE FOUR WORD ENTRY FOR EACH DRIVER AVAILABLE IN THE CURRENT
	SYSTEM.  THE FIRST WORD GIVES THE DRIVER NAME PACKED MOD 40.
	THE SECOND GIVES THE CORE ADDRESS IF RESIDENT IN CORE.  THE
	THIRD GIVES THE DEVICE'S INTERRUPT ADDRESS, AND THE FOURTH
	IS CONSTRUCTED BY INITIALIZATION TO GIVE THE DISK ADDRESS
	AND LENGTH IF THE DRIVER IS DISK RESIDENT.

	MINIMAL TELETYPE HANDLER - THIS HANDLER IS THE BASIC INTERRUPT
	PROCESSOR FOR THE TELETYPE.  IN ADDITION IT WILL RECOGNIZE ^C
	INPUT AND STORE A MONITOR MESSAGE.

	DISK I/O HANDLER - THE DISK I/O HANDLER FOR THE SYSTEM DISK
	MUST BE RESIDENT TO ALLOW LOADING OF SWAP AREA ROUTINES (SEE
	BELOW), ETC.

	EMT TRAP HANDLER - CONTAINS TABLE AND INSTRUCTIONS TO DECODE
	EMT CODES AND LOCATE THE ROUTINE TO SERVICE EACH EMT.

	QUEUE MANAGER - THE QUEUE MANAGER (DISCUSSED BELOW) MUST BE 
	RESIDENT TO AVOID QUEUEING REQUESTS FOR THE QUEUE MANAGER.

	SWAP AREA AND ROUTINES - THIS AREA OF THE MONITOR IS USED TO
	MANAGE MONITOR ROUTINES WHICH ARE NOT PERMANENTLY RESIDENT.

	BUFFER MANAGEMENT ROUTINES - THE ROUTINES WHICH PERFORM CORE
	MANAGEMENT ARE RESIDENT TO PROVIDE A FAST RESPONSE TO THESE
	REQUESTS.

11.1.2	FLOW THROUGH THE MONITOR (MACRO)

	MONITOR REACTION TO A REQUEST BY A USER (THROUGH EMT) WILL 
	BE AS FOLLOWS:

	1)  THE EMT TRAP VECTOR WILL POINT TO THE EMT MANAGER SO
	    CONTROL WILL INITIALLY BE GIVEN TO THIS ROUTINE.

	2)  THE EMT TRAP MANAGER WILL CONVERT THE TRAP CODE INTO A 
	    REQUEST FOR A SPECIFIC MONITOR ROUTINE.

	    A)  IF THE ROUTINE IS RESIDENT IN CORE (AS SHOWN BY MRT)
		CONTROL IS GIVEN TO THE ROUTINE

	    B)  IF THE REQUESTED ROUTINE IS NOT CURRENTLY RESIDENT
		IN CORE, CONTROL IS TRANSFERRED TO THE SWAP AREA
		MANAGER (SAM).  THE SAM THEN LOADS THE ROUTINE INTO 
		THE MONITOR SWAP BUFFER (MSB) AS SOON AS THE MSB IS 
		AVAILABLE.

11.2	LIBRARY CONFIGURATION

	THE DISK MONITOR ROUTINES AND THEIR REQUIRED SUPPORT FUNCTIONS
	WILL BE ORGANIZED INTO SEVERAL SEPARATE "LIBRARIES".  THE 
	CONTENTS OF EACH LIBRARY ARE SHOWN BELOW:

11.2.1	LIBRARY TYPES 

	MONITOR LIBRARY - THIS LIBRARY IS DISK RESIDENT WITH SELECTED
	PORTIONS BEING ALSO CORE RESIDENT FOR SELECTED INTERVALS.
	THIS LIBRARY IS WRITTEN IN POSITION INDEPENDENT CODE AND
	IS STORED IN DIRECTLY LOADABLE ABSOLUTE BINARY (LOAD FORMAT).
	ALL ROUTINES BEGIN AT ABSOLUTE ZERO.

	SUBROUTINE LIBRARY - THIS LIBRARY CONTAINS COMMONLY USED SUB-
	PROGRAMS SUCH AS SQRT.  IT MAY EXIST ON DECTAPE OR DISK AND
	IT IS STORED IN RELOCATABLE BINARY.

	MACRO LIBRARY - THIS LIBRARY CONTAINS MACRO DEFINITIONS IN ASCII
	SOURCE LANGUAGE.  IT MAY BE LOCATED ON DISK OR DECTAPE.  USER
	LIBRARIES - ANY USER MAY GROUP ANY SET OF HIS OWN RELOCATABLE
	BINARY ROUTINES AND SUBROUTINES TOGETHER BY USING THE LIBRARIAN
	AND SO FORM A USER LIBRARY.  THIS LIBRARY MAY THEN BE PRESENTED
	AS AN ENTITY TO SUCH SYSTEM ROUTINES AS THE LINKER OR PIP.

11.2.2	LIBRARY DIRECTORYS

	THE LIBRARIES WILL ALL HAVE A SIMILAR CONSTRUCTION SO THAT A
	SINGLE LIBRARIAN ROUTINE CAN MANAGE ALL OF THEM.  EACH LIBRARY
	WILL BE CONSTRUCTED AS FOLLOWS:

	1)  EACH LIBRARY WILL HAVE A DIRECTORY WHICH RESIDES WITHIN
	    THE LIBRARY ITSELF.  THE DIRECTORY WILL CONSIST OF
	    BLOCKS OF DATA WHICH ARE LINKED TOGETHER WITHIN THE 
	    LIBRARY.

	2)  EACH DIRECTORY BLOCK WILL CONTAIN SEVERAL VARIABLE
	    SIZE ELEMENTS.  THERE WILL BE ONE OF THESE ELEMENTS
	    TO REPRESENT EACH ROUTINE CONTAINED IN THE LIBRARY.
	    EACH DIRECTORY ELEMENT WILL HAVE THE FOLLOWING FORMAT:

		ROUTINE
		NAME (PACKED MOD 40)

		STARTING BLOCK ADDRESS
		LENGTH OF ROUTINE
		     IN WORDS

		NUMBER OF WORDS
		FOLLOWING IN THIS ELEMENT

		N WORDS ADDITIONAL
		    INFORMATION

	EACH LIBRARY WILL BE TREATED AS A FILE BY THE SYSTEM, HENCE IT
	WILL BE LOCATED THRU ITS ENTRY IN THE FILE DIRECTORY STRUCTURE.

11.3	OTHER MONITOR FUNCTIONS

	MONITOR FUNCTIONS WHICH WILL BE PROVIDED IN ADDITION TO THOSE
	DISCUSSED EARLIER WILL BE DISCUSSED HERE.  THESE ROUTINES MAY
	BE EITHER CORE RESIDENT OR SWAPPED FROM DISK.  THE USER MAKES
	THIS DETERMINATION FOR HIMSELF AT SYSTEM GENERATION TIME.

11.3.1	LOADING

	THE LOADING OF PROGRAMS WILL BE ACCOMPLIAHED IN TWO PHASES:
	THE LOCATE PHASE AND THE LOAD PHASE.  THE LOCATE PHASE OF THE
 	LOADER OPERATES AS A USER PROGRAM IN THE USER CODE AREA.
	ITS FUNCTION IS TO LOCATE THE PROGRAM TO BE LOADED ON THE
	DISK AND GIVE THE ABSOLUTE LOADER A DISK ADDRESS TO LOAD 
	FROM AND A CORE ADDRESS TO LOAD INTO.  THIS PHASE OF THE
	LOADER HANDLES THE KEYBOARD RUN AND GET COMMANDS.  WHEN LOCATING
	A PROGRAM THE GENERAL FILES ARE SEARCHED (ON FILE NAME).  THE
	LOAD PHASE THEN DOES THE PHYSICAL LOADING.  THIS ROUTINE
	OPERATES AS A MONITOR SWAPPABLE ROUTINE.

11.3.2	TELETYPE MESSAGE PROCESSING

	11.3.2.1 THE MINIMAL TELETYPE HANDLER

	THE MINIMAL TELETYPE HANDLER WILL HANDLE TELETYPE INTERRUPTS.
	IT WILL COLLECT ALL CHARACTERS BETWEEN ^C AND CARRIAGE RETURN
	(SEE SECTION 8 FOR TELETYPE COMMAND LANGUAGE).  AT THE APPEAR-
	ANCE OF THE CARRIAGE RETURN THE TELETYPE HANDLER REQUESTS THE
	SAM TO RUN THE KEYBOARD COMMAND INTERPRETER IN THE MSB.  IT 
	WAS DETERMINED THAT THE TELETYPE HANDLER ITSELF WOULD BUFFER
	THE MESSAGE SO THAT THE MSB WOULD BE "FREE" FOR THE OTHER 
	FUNCTIONS DURING THE RELATIVELY SLOW TYPE-IN.  ALL CHARACTERS
	BETWEEN CARRIAGE RETURN AND ^C WILL BE BUFFERED FOR USER ACTION.

	11.3.2.2 THE KEYBOARD COMMAND INTERPRETER

	THE KEYBOARD COMMAND INTERPRETER CONSISTS OF A MAIN INTERPRETING
	ROUTINE AND SEPARATE ROUTINES TO HANDLE EACH SPECIFIC COMMAND.
	THE INTERPRETER WILL BE CALLED BY THE MINIMAL TELETYPE HANDLER
	WHENEVER A COMPLETE MONITOR COMMAND HAS BEEN RECEIVED.  THE
	INTERPRETER WILL DETERMINE THE TYPE OF MESSAGE AND THE PARTI-
	CULAR SERVICING ROUTINE TO BE CALLED ACCORDING TO AN INTERNAL
	TABLE.  THE SPECIFIC ROUTINE WILL PROCESS THE MESSAGE
	AND PERFORM THE REQUESTED ACTION (SEE SECTION 8).

11.3.3	BUFFER MANAGEMENT

	THE BUFFER MANAGEMENT SCHEME SELECTED IS DEPENDENT ON THE
	FOLLOWING CONSIDERATIONS:

	1)  BUFFERS ARE TO BE ALLOCATED FROM "FREE" CORE AREA;

	2)  BUFFERS WILL BE OF FIXED SIZE FOR ALL DEVICES.

(11.3.3 CONT'D)

	THE SECOND ASSUMPTION REQUIRES SOME FURTHER DISCUSSION.  THE
	FIXED BUFFER SIZE CHOSEN IS 16 WORDS.  THE DECTAPE BUFFER SIZE 
	IS A MULTIPLE OF THE BASIC SIZE (I. E. 256 WORDS).  SIMILIARLY,
	OTHER DEVICES WILL USE A MULTIPLE OF 16 WORDS, FOR EXAMPLE, 64
	WORD BUFFER FOR PAPER TAPE PUNCH AND 64 WORDS FOR PAPER 
	TAPE READER.  THE TELETYPE HANDLER WILL MAINTAIN A
	ONE WORD INTERNAL BUFFER SO THAT NO MINUMUM TYPE-IN REQ-
	QUIREMENT IS IMPLIED.  A DEVICE SUCH AS A PRINTER WHICH
	REQUIRES A BUFFER WHICH IS NOT AN EXACT MULTIPLE OF 64 (I.E. 120
	CHARACTERS) WILL REQUEST ENOUGH SPACE (I.E. 64 WORDS) TO 
	SATISFY ITS REQUIREMENTS AND THE EXTRA SPACE (4 WORDS) WOULD
	BE WASTED.  THIS SMALL AMOUNT OF DYNAMIC "WASTE" SPACE SHOULD
	BE MORE THAN COMPENSATED FOR BY ALLOWING A VERY SMALL, FAST 
	BUFFER ALLOCATION SCHEME.


(11.3.3 CONT'D)

	THE BUFFER MANAGEMENT FUNCTION IS THE MANAGEMENT OF THE "FREE
	CORE" AREA BETWEEN THE MONITOR AND THE USER PROGRAM.  THIS
	DYNAMICALLY ALLOCATED AREA IS REQUIRED FOR TRANSIENT USE OF 
	DISK RESIDENT DRIVERS, FOR BUFFERS, FOR DDB'S, FOR FIB'S AND
	FOR OTHER TRANSIENT MONITOR ROUTINES.  THE AREA IS ALLOCATED
	IN 16 WORD BLOCKS (ANY NUMBER OF CONTIGUOUS BLOCKS MAY BE
	REQUESTED).  THE BUFFERS ARE ALLOCATED FROM THE TOP OF THE 
	MONITOR UPWARDS TO ALLOW THE MAXIMUM AREA FOR THE USER STACK.
	BUFFERS ARE RETURNED WHEN THEIR FUNCTIONS IS COMPLETE, HOWEVER
	THE SPACE THEY OCCUPIED IS RETURNED TO THE "FREE" POOL ONLY
	FROM THE TOP DOWN, I.E. NO DYNAMIC SHUFFLING OF BUFFERS IS
	PERFORMED AND A BUFFER IS ONLY DEALLOCATED WHEN ALL BUFFERS
	ABOVE IT ARE ALSO FREE.  THE BUFFER MANAGER MANIPULATES THE 
	STACK PROTECTION INFORMATION SO THAT ALL CURRENTLY ALLOCATED 
	BUFFERS ARE PROTECTED (SEE REGISTER SAVE/RESTORE BELOW).



11.3.4	DUMPS

	THE DUMP ROUTINE PROVIDES THE OPERATOR WITH THE CAPABILITY TO
	WRITE SELECTED CORE AREAS ON A SPECIFIED DEVICE.  THE OPERATOR
	THEN CAN RUN A DUMP FORMATTING ROUTINE WHICH WILL FORMAT THE 
	DUMP AND TRANSFER IT TO ANOTHER DEVICE OR FILE E.G., LIST THE 
	DUMP (OR SELECTED PORTIONS THEREOF) ON THE LINE PRINTER.

11.3.5	EXIT

	THE EXIT ROUTINE PROVIDES FOR THE CLEAN UP OF ALL PREVIOUS 
	MONITOR REQUESTS FOR A PROGRAM AND INFORMS THE MONITOR THAT
	THE PROGRAM HAS FINISHED EXECUTION.  THE MONITOR COMPLETES
	ALL I/O OPERATIONS WHICH THE PROGRAM HAS PENDING AND CLOSES ALL
	OPEN FILES.  HOOKS WILL BE PROVIDED HERE FOR A USER WRITTEN 
	ACCOUNTING ROUTINE AND FOR THE CONTINUATION OF PROCESSING UNDER
	CONTROL OF THE CONCISE COMMAND LANGUAGE (CCL).

11.3.6	KEYBOARD & USER REQUESTED FUNCTIONS

	ROUTINES WILL BE PROVIDED TO PERFORM ALL FUNCTIONS AS
	DESCRIBED IN SECTION 8.

11.3.7	RADIX 40 PACK AND UNPACK.

	SINCE SEVERAL SYSTEM ROUTINES WILL MAKE USE OF THE EFFICIENCIES
	OF RADIX 40 PACKING THESE ROUTINES ARE PROVIDED FOR COMMON USE.

11.3.8	EXTENSIONS

	AS OTHER ROUTINES OF FAIRLY COMMON USAGE EMERGE THESE WILL ALSO
	BE INCLUDED WITHIN THE MONITOR SO THAT SYSTEM (AND USER) PRO-
	GRAMS CAN MAKE USE OF THIS EFFICIENCY.  THEY WILL BE REFERENCED
	THROUGH THE EMT INSTRUCTION.

11.3.9	LIBRARIAN

	A LIBRARIAN TO MAINTAIN THE VARIOUS SYSTEM LIBRARIES WILL BE
	PROVIDED.  THIS ROUTINE WILL RUN AS A USER PROGRAM AND IT WILL
	HAVE THE CAPABILITY TO INSERT AND DELETE FILES IN THE LIBRARY,
	LIST THE LIBRARY TABLE OF CONTENTS, ETC.

11.3.10	REGISTER SAVE/RESTORE

	A COMMON REGISTER SAVE/RESTORE ROUTINE IS PROVIDED FOR USE 
	OF ANY MONITOR ROUTINE.  SINCE REGISTERS ARE SAVED UPON ENTRY
	TO THE MONITOR, THE REQUIRED STACK OVERFLOW CHECKS MAY BE
	MADE HERE.  HENCE THE SAVE ROUTINE DETERMINES IF THE TOP 
	OF THE MONITOR (TOP OF THE BUFFER AREA) IS NOW OR EVER HAS 
	BEEN IMPINGED UPON BY THE STACK.  IF THIS HAS OCCURRED THE
	APPROPRIATE FATAL DIAGNOSTIC WILL BE ISSUED.

11.3.10	MONITOR QUEUES

	11.3.10.1 INTRODUCTION

	THE PROPOSED I/O HANDLING STRUCTURE FOR THE PDP-11 DISK MONITOR
	COULD POSSIBLY REQUIRE THE FOLLOWING QUEUES.

	A)  MULTIPLE REQUESTS FOR THE SERVICES OF A DEVICE HANDLER 
	    ASSOCIATED WITH SEVERAL DATA SETS.

	B)  REQUIREMENTS FOR BUFFERS WHEN THERE IS NO FURTHER FREE CORE
	    AND ALL EXISTING BUFFERS ARE IN USE.

	EACH TYPE OF QUEUE WILL HAVE ITS OWN PECULIAR CHARACTERISTICS.
	IT IS, THEREFORE, SUGGESTED THAT A DIFFERENT TREATMENT BE
	APPLIED TO EACH RATHER THAN HAVE A COMPLEX COMMON HANDLING
	PROCEDURE.

	IN EACH CASE, IT IS, OF COURSE, ASSUMED THAT CONTROL
	WILL BE RETURNED TO THE CALLING PROGRAM ONCE THE ENTRY INTO
	THE QUEUE HAS BEEN MADE, SO THAT ALTERNATIVE PROCESSING MAY 
	BE CONTINUED FOR AS LONG AS THIS IS POSSIBLE.  THE MANIPULATION
	OF THE QUEUE WILL THEN BE EFFECTED WITHIN THE MONITOR WHEN 
	APPROPRIATE.

	11.3.10.2 DEVICE REQUESTS

	QUEUES FOR DEVICE DRIVERS' SERVICES ARE THE ONLY TYPE
	CURRENTLY PROVIDED FOR.  DEVICE DRIVER QUEUEING IS BASED
	ON THE FOLLOWING CHARACTERISTICS OF THE MONITOR I/O.

	A)  ANY DATA-SET MUST BE ASSOCIATED WITH JUST ONE DEVICE
	    AND CAN SUSTAIN ONLY ONE OPERATION AT A TIME UPON
	    THAT DEVICE.  AS A RESULT, THE COMBINED LENGTH OF
	    ALL DEVICE REQUEST QUEUES CAN NEVER EXCEED THE NUM-
	    BER OF DATA-SETS SO FAR ESTABLISHED.  IN THE WORST
	    CASE WHEN ALL DATA-SETS ARE SHARING THE SAME DEVICE,
	    IT WILL ACTUALLY BE ONE LESS, SINCE ONE OF THE SETS
	    MUST BE GETTING THE SERVICE REQUIRED.

	B)  BEFORE ANY I/O OPERATION IS ATTEMPTED UPON A DATA-
	    SET, ITS DDB LINKAGE MUST HAVE BEEN SET UP.
	    THIS BLOCK WILL ALREADY CONTAIN THE INFORMATION NEEDED FOR 
	    QUEUE CONTROL.  THE QUEUE ITSELF NEED THUS CONSIST MERELY
	    OF AN APPROPRIATELY LINKED CHAIN OF THE RELEVANT DDB ADDRESSES. 

	C)  THE EXTRACTION OF THE NEXT ELEMENT FROM THE QUEUE
	    FOR A DEVICE IS DEPENDENT UPON THE DEVICE COMPLETING
	    ITS CURRENT TASK.

	    EACH HANDLER CAN THEREFORE BE GIVEN THE RESPONSI-
	    BILITY FOR EXITING TO A COMMON MONITOR ROUTINE WHICH
	    WILL CHECK IF A QUEUE EXISTS FOR THAT HANDLER AND
	    IF SO, INITIATE ACTION UPON THE NEXT REQUEST IN THE
	    QUEUE.

	THE LINKED CHAIN MENTIONED ABOVE WILL USE A QUEUE-WORD WHICH WILL 
	BE SET UP WITHIN EACH B.I.B AND WHICH WILL NORMALLY CONTAIN 0.
	THE PROCESS OF BUILDING THE QUEUE WILL COVER 3 STAGES (SEE
	APPENDIX C FOR AN ILLUSTRATION).

	1)  BEFORE A MONITOR PROCESSING ROUTINE CALLS A HANDLER, IT WILL
	    CHECK THE BUSY STATE OF THAT HANDLER BY EXAMINING A WORD
	    WITHIN IT WHICH WILL BE SET TO THE ADDRESS OF THE B.I.B. FOR
	    THE DATA-SET ON WHICH IT MAY BE CURRENTLY OPERATING.  IF THE
	    WORD CONTAINS A 0, THE HANDLER IS IDLE; THE CALL WILL BE 
	    MADE AND THE WORD SET ACCORDINGLY.

	2)  THE WORD WILL STILL BE NON-ZERO IF A SECOND REQUEST ARISES
	    FOR THE HANDLER BEFORE THE FIRST IS SATISFIED.  IN THIS 
	    CASE, THE QUEUE-WORD IN THE B.I.B. REPRESENTING THE CURRENT
	    I/O ACTIVITY WILL BE EXAMINED BY A QUEUE MANAGEMENT ROUTINE.
	    IF THIS IS ZERO, IT WILL BE RESET TO THE ADDRESS OF THE 
	    B.I.B. FOR THE DATA-SET FOR THE SECOND REQUEST AND THIS 
	    WILL BECOME THE FIRST ELEMENT OF THE QUEUE.

(11.3.10.2 CONT'D)

	3)  IF A QUEUE HAS ALREADY BEEN STARTED AND THE DEVICE STAYS
	    BUSY, ANY SUBSEQUENT REQUEST WILL BE ADDED TO THE QUEUE BY
	    RESETTING THE QUEUE-WORD WITHIN ANY DDB TO THE ADDRESS
	    OF THE DDB FOR THE NEXT ELEMENT IN THE CHAIN.  PRIORIT-
	    IES, HOWEVER, WILL BE CONSIDERED; THE QUEUE MANAGER WILL CHECK
	    THE PRIORITY-LEVEL STORED WITHIN EACH DDB AS IT TRACES
	    THE QUEUE FOR A NEW ENTRY AND WILL INSERT THAT ENTRY AS THE
	    LAST ITEM AT THE REQUIRED LEVEL.  ALTHOUGH THIS COULD TAKE 
	    SOME TIME, THE TRACING PROCESS WILL BE THUS CARRIED OUT AT
	    THE LEVEL OF THE CALLING PROGRAM.

	AT THE INTERRUPT LEVEL, WHEN THE HANDLER DETERMINES THE END
	OF ITS CURRENT TASK, DEQUEUEING IS MERELY A MATTER OF PICKING
	UP THE NEXT LINK IN THE CHAIN FOR ACTION WITHOUT FURTHER SEARCH.

	IT IS APPRECIATED THAT SHOULD A QUEUEING SITUATION NEVER
	ACTUALLY OCCUR, A WORD IN EVERY DDB MAY BE WASTED; THE
	METHOD NEVERTHELESS DOES COMMEND ITSELF.  IN THE FIRST PLACE,
	QUEUE SPACE WILL AUTOMATICALLY EXPAND AND CONTRACT IN ACCORDANCE
	WITH THE NUMBER OF DATA-SETS CURRENTLY OPEN AND THEREFORE 
	LIKELY TO NEED IT.  THIS IS MORE PRACTICAL THAN HAVING A SPECIAL
	AREA DEFINED AT A SOMEWHAT INDETERMINABLY FIXED LENGTH.  SECOND-
	LY, A FIXED QUEUE-TABLE WOULD PROBABLY REQUIRE AT LEAST TWO
	WORDS PER ELEMENT - ONE TO CONTAIN THE DDB ADDRESS AS IDENT-
	IFICATION AND THE SECOND TO PROVIDE THE LINKAGE BETWEEN ELEMENTS
	ON A PRIORITY BASIS.  ALSO, SINCE THE NUMBER OF DATA-SETS IN
	USE AT ONE TIME IS UNLIKELY TO BE VERY LARGE IN THE AVERAGE 
	PROGRAM ANY WASTAGE IS MINIMAL.

	11.3.10.3 BUFFER REQUESTS

	ALTHOUGH THE NEED FOR BUFFER QUEUEING MAY DOUBTLESS OCCUR,
	IT IS WORTHWHILE TO CONSIDER WHETHER OR NOT PROVISIONS FOR THIS
	IS JUSTIFIED FOR THE GENERAL CASE.

	THE SOLE OBJECT OF SETTING UP A QUEUE IS TO MAKE PROVISION FOR
	SITUATIONS IN WHICH, ALTHOUGH REQUESTS FOR SERVICES MAY NOT
	BE IMMEDIATELY GRANTED, THERE IS A REASONABLE HOPE THAT THEY 
	WILL BE SATISFIED SOMETIME.  THIS IS CERTAINLY THE CASE WITH 
	CALLS UPON DEVICES, BUT IT IS NOT SO WITH BUFFERS.

	SHOULD A BUFFER BE WANTED WHEN THERE ARE NONE AVAILABLE AND 
	FREE CORE IS TOO RESTRICTED TO ALLOW A NEW ONE TO BE ALLOCATED,
	THERE ARE ONLY TWO CHANCES OF EVENTUAL RECOVERY:

	1)  IF EXISTING BUFFERS ARE RETURNED FAIRLY FREQUENTLY TO THE 
	    POOL, REQUESTS WAITING IN A QUEUE ARE LIKELY TO BE ANSWERED
	    BEFORE IMPASSE IS REACHED.  MOREOVER, THE ROUTINE TO 
	    HANDLE BUFFER RELEASE CAN BE CHARGED WITH THE FUNCTION OF
	    DEQUEUEING.

	2)  THERE IS A POSSIBILITY THAT THE PUSH-DOWN STACK ALSO 
	    OCCUPYING FREE CORE MAY RECEDE SUFFICIENTLY TO ALLOW MORE
	    BUFFER SPACE.  HOWEVER, THIS CAN ONLY BE DETERMINED BY FREQUENT
	    EXAMINATION OF THE FREE CORE STATE BY THE MONITOR, PERHAPS
	    AT EVERY EXIT TO THE USER, WITH A CONSEQUENT INCREASE 
	    IN OVERHEAD PENALTY.

	IN EITHER EVENT, THE SITUATION IS SO GOVERNED BY THE WAY THE
	USER WRITES HIS PROGRAM THAT THE INITIAL VERSION OF THE SYSTEM,
	NO ATTEMPT WILL BE MADE BY THE MONITOR TO SET UP A BUFFER QUEUE.
	INSTEAD THE USER WILL SPECIFY, WITHIN THE DATA-SET LINK-BLOCK 
	IN HIS PROGRAM, AN ADDRESS TO WHICH CONTROL WILL BE TRANSFERRED
	WHENEVER BUFFER PROVISION BECOMES IMPOSSIBLE SO THAT HE MAY
	TAKE ALTERNATIVE ACTION.

11.3.11	COMMAND STRING INTERPRETER

	NOT YET AVAILABLE.

11.4	INITIALIZATION

	WHEN THE MONITOR IS LOADED INTO CORE FROM DISK, THE
	INITIALIZATION ROUTINE IS RUN AUTOMATICALLY.  THE PURPOSE
	OF THIS ROUTINE IS TO DETERMINE VALUES FOR DATA WHICH VARY
	BETWEEN DIFFERENT MONITORS AND INITIALIZE VARIOUS TABLES
	AND VECTORS BASED ON THIS DATA.  THE FOLLOWING FUNCTIONS
	ARE PERFORMED:

	    SYSTEM VECTOR TABLE
		DETERMINE CORE SIZE AND SET INITAL STACK PROTECTION.
	    VECTORS
		SET UP EMT VECTOR AND SET ALL OTHER VECTORS TO POINT TO THE ERROR ROUTINE.
	    DEVICE DRIVER LIST
		SET UP VECTORS FOR RESIDENT DRIVERS.  DETERMINE DISK
		ADDRESS OF NON RESIDENT DRIVERS
	    MONITOR RESIDENT TABLE
		LOACATE DISK RESIDENT ROUTINES AND PLACE THEIR ADDRESSES 
		IN THE MRT SET ALL UNAVAILABLE ENTRYS TO ONE
	    MONITOR LIBRARY
		SET EMT CODES IN THE MONITOR LIBRARY DIRECTORY
	    SYSTEM DISK
		PLACE AN INITIALIZED COPY OF THE MRT ON THE SYSTEM 
		RESIDENCE DISK SO THAT THE MRT UPON COMPLETION OF
		INITIALIZATIONS AN APPROPRIATE MESSAGE IS TYPED OUT AND
		THE MONITOR IS READY FOR ANY DESIRED REQUEST.

11.5	DEVICE DRIVER FORMAT

	NOT AVAILABLE YET.



 